Editing Multitier architecture (section)

===Common layers===
In a logical multilayer architecture for an information system with an [[object-oriented design]], the following four are the most common:

* '''Presentation layer''' (a.k.a. UI layer, view layer, presentation tier in multitier architecture)
* '''Application layer''' (a.k.a. [[Service layer pattern|service layer]]<ref>[http://martinfowler.com/eaaCatalog/serviceLayer.html Martin Fowler's Service Layer]</ref><ref>[http://martinfowler.com/bliki/AnemicDomainModel.html Martin Fowler explains that Service Layer is the same as Application Layer]</ref> or [[GRASP (object-oriented design)|GRASP]] Controller Layer <ref>[https://archive.today/20120715125904/http://tech.groups.yahoo.com/group/domaindrivendesign/message/7582 Comparison/discussion of the GRASP Controller Layer vs. Application/Service Layer]</ref>)
* '''[[Business logic|Business layer]]''' (a.k.a. business logic layer (BLL), domain logic layer)
* '''[[Data access layer]]''' (a.k.a. [[persistence layer]], logging, networking, and other services which are required to support a particular business layer)

If the application architecture has no explicit distinction between the business layer and the presentation layer (i.e., the presentation layer is considered part of the business layer), then a traditional client-server (two-tier) model has been implemented.{{citation needed|date=February 2014}}

The more usual convention is that the application layer (or service layer) is considered a sublayer of the business layer, typically encapsulating the API definition surfacing the supported business functionality. The application/business layers can, in fact, be further subdivided to emphasize additional sublayers of distinct responsibility. For example, if the [[model–view–presenter]] pattern is used, the presenter sublayer might be used as an additional layer between the user interface layer and the business/application layer (as represented by the model sublayer).{{citation needed|date=February 2014}}

Some also identify a separate layer called the business infrastructure layer (BI), located between the business layer(s) and the infrastructure layer(s). It is also sometimes called the "low-level business layer" or the "business services layer".  This layer is very general and can be used in several application tiers (e.g. a CurrencyConverter).<ref name="craiglarman.com">[http://www.craiglarman.com/wiki/index.php?title=Books#Applying_UML_and_Patterns ''Applying UML and Patterns'', 3rd edition, page 203] {{ISBN|0-13-148906-2}}</ref>

The infrastructure layer can be partitioned into different levels (high-level or low-level technical services).<ref name="craiglarman.com"/>  Developers often focus on the persistence (data access) capabilities of the infrastructure layer and therefore only talk about the persistence layer or the data access layer (instead of an infrastructure layer or technical services layer). In other words, the other kind of technical services is not always explicitly thought of as part of any particular layer.{{citation needed|date=February 2014}}. The Data Access layer normally contains an object known as the [[Data_access_object|Data Access Object (DAO)]].

A layer is on top of another, because it depends on it.  Every layer can exist without the layers above it, and requires the layers below it to function. Another common view is that layers do not always strictly depend on only the adjacent layer below. For example, in a relaxed layered system (as opposed to a strict layered system) a layer can also depend on all the layers below it.<ref name="posa" /> The relaxed layered system has more couplings and subsequently it's more difficult to change. Multi-tier architectures can use a hybrid approach so that some layers are strict while other layers are relaxed.<ref>{{Cite book |last=Richards |first=Mark |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |isbn=978-1492043454 |edition=1st |publication-date=March 3, 2020}}</ref><ref>{{Cite book |last=Richards |first=Mark |title=Software Architecture Patterns |publisher=O'Reilly Media, Inc}}</ref>