Layers Pattern
The layers pattern is one of the most used (and abused) architecture patterns. Most software systems have multiple contributors. Partitioning code into distinct and independent layers organized around a specific set of related concerns enables developers to work together better. Layers promote decreased coupling between the layers and higher cohesion within, which promotes maintainability. Use layers any time you need to change code modules independently of one another.
Category | Module |
Elements | Layer—group of functionally cohesive modules. |
Relations | Allowed to use—indicates which layers may use modules within another layer. |
Rules for Use |
Every module must be allocated to one and only one layer. Layers above are allowed to use layers below, but this relation only goes one way. The allowed to use relation can be limited so the current layer may only use the layer immediately below it. Cyclical dependencies are not permitted. |
Strengths | Promotes maintainability, portability, reusability, testability, design time modifiability. Conceptually simple to implement. Layers can be made visible in the code. |
Weaknesses | Each layer introduces additional abstractions between the highest layers and the lowest. These additional abstractions increase complexity and may harm performance. Too many layers or leaky abstractions can make development painful for programmers. |
Here are examples of layered diagrams. The diagram on the left explicitly shows the allowed to use relation, whereas the diagram on the right implies relations among elements.
There many variants of the layered pattern. No matter how it’s drawn or how many layers are involved, the elements, relations, and rules for their use are the same.