Multilayered architecture

From Wikipedia, the free encyclopedia

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

There is also an architectural pattern called "Layers" that's been described in various publications, including the book, Pattern-Oriented Software Architecture, A System of Patterns.[1]

The terms "tier" and "layer" are often used interchangeably. However, many 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 a entire software solution.[2]

Common layers

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

There is a book called Domain Driven Design[6] that described some common uses for the above four layers, though its primarily focus is the domain layer.

There is often no explicit distinction between the business layer and the application layer (i.e., the application layer may be considered part of the business layer). On the other hand, one might further divide the application/business layers. For example, if the Model View Presenter pattern is used, the presenter layer might be used as an additional layer between the user interface layer and the application layer.

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 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 explicitly thought of as part of any particular layer.

There is also a view that all types are not always exclusive to one particular layer, according to the "POSA book"[8] 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

  1. ↑ http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html Pattern-Oriented Software Architecture A System of Patterns
  2. ↑ Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices)
  3. ↑ Martin Fowler's Service Layer
  4. ↑ Martin Fowler's 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.
  7. ↑ 7.0 7.1 Applying UML and Patterns, 3rd edition, page 203, ISBN 0-13-148906-2
  8. ↑ Pattern-Oriented Software Architecture A System of Patterns, p. 39.

See also

External links

This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.