Multilayered architecture
A multilayered software architecture is a software architecture that uses many layers for allocating the responsibilities.
There is also an architectural pattern that is named Layers and has been described in different publications, including the book Pattern-Oriented Software Architecture, A System of Patterns.[1]
The concepts of layer and tier are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure. [2]
Common layers
In a logical multilayered 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[3][4] or GRASP Controller Layer [5])
- Business layer (a.k.a business logic layer (BLL), domain layer)
- Infrastructure layer (data access layer, persistence layer, logging, networking, and other services which are required to support a particular business layer.)
Some common purposes of the above four layers are for example described in the book about domain-driven design [6] at page 68-74, which is a book that otherwise is focused on describing the domain layer.
Sometimes there is no explicit distinction between the business layer and the application layer, e.g. the application layer is considered as being a part of the business layer. On the other hand, it is also possible to even further divide the application/business layers into more layers. For example, if the Model View Presenter pattern is used, then the presenter layer could be considered to be an additional layer between the user interface layer and the application layer.
The business layer can also use a business Infrastructure Layer (aka low-level business 'services' layer) logically positioned between business layer(s) and infrastructure layer(s). That layer (BI) is very general and can be used in several application tiers, e.g. a CurrencyConverter.[7]
The infrastructure layer may be partitioned into different levels (high-level or low-level technical services)[7]. Though, it is not unusual that developers only consider the persistence (data access) 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 are not always being explicitly thought of as being part of any particular layer.
Regarding that all types are not always considered as belonging to one particular layer, according to the "POSA book" (Pattern-Oriented Software Architecture A System of Patterns, page 39) a relaxed layered system (as opposed to a strict layered system) can use so called "shared data definition modules" which are types not belonging in a particular layer.
Notes
- ^ http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html Pattern-Oriented Software Architecture A System of Patterns
- ^ Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices)
- ^ Martin Fowler's Service Layer
- ^ Martin Fowler's explains that Service Layer is the same as Application Layer
- ^ Comparison/discussion of the GRASP Controller Layer vs. Application/Service Layer
- ^ Domain-Driven Design, the Book
- ^ a b Applying UML and Patterns, 3rd edition, page 203, ISBN 0-13-148906-2