Multilayered architecture

A multilayered software architecture is a software architecture that uses many layers for allocating the different responsibilities of a software product.

The "Layers" architectural pattern has been described in various publications.[1]

The terms "tier" and "layer" are often used interchangeably. Most experts recognize a distinction between the two, where 'tier' is used when representing the physical layout of the various mechanisms in a system's infrastructure, while 'layer' is used when representing the orientation of the different physical or conceptual elements that make up an entire software solution. For example, a three-layer solution could easily be deployed on a single tier, such as a personal workstation.[2]

Common layers

In a logical multilayered architecture for an information system with an object-oriented design, the following four are the most common:

The book Domain Driven Design describes some common uses for the above four layers, although its primary focus is the domain layer.[6]

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.

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).

Some also identify a separate layer called the business infrastructure layer (BI), located between the business layer(s) and the infrastructure layer(s). It's 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).[7]

The infrastructure layer can be partitioned into different levels (high-level or low-level technical services).[7] 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 are not always explicitly thought of as part of any particular layer.

Another common view is that all types are not always exclusive to one particular layer. For example, 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.[1]

See also

References

  1. 1 2 Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter; Stal, Michael (1996-08). Pattern-Oriented Software Architecture, Volume 1, A System of Patterns. Wiley, August 1996. ISBN 978-0-471-95869-7. Retrieved from http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html.
  2. ↑ Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices)
  3. ↑ Martin Fowler's Service Layer
  4. ↑ Martin Fowler explains that Service Layer is the same as Application Layer
  5. ↑ Comparison/discussion of the GRASP Controller Layer vs. Application/Service Layer
  6. ↑ Domain-Driven Design, the Book pp. 68-74. Retrieved from http://www.domaindrivendesign.org/books#DDD.
  7. 1 2 Applying UML and Patterns, 3rd edition, page 203, ISBN 0-13-148906-2

External links

This article is issued from Wikipedia - version of the Tuesday, March 08, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.