Layered Architectures

The Layered architectural pattern describes the widely used principle of decomposing a complex task into a number of subtasks. Almost any development team and organization where I have worked claimed to use this principle in their developments. Most classes or books on software engineering emphasize the notion of decomposing systems into layers and defining interfaces between them. So, when I saw the name “layered architecture” my first impression was that it is a basic and fundamental concept. When I started reading the pattern I found very interesting that the authors mentioned at the beginning that most systems that people claim to use layered architectures are either a collection of multiples architectural styles or just some collection of cooperating components without clear boundaries. In this pattern the author attempts to give a more rigorous definition and properties of corrects layered architectures.

Some of the important ideas to keep in mind when designing a layered architecture includes: localizing changes to one part of the system, cohesion within components and loose coupling between unrelated components, avoid crossing too many components, reusable parts and parts that can be exchanged by different implementations without affecting other layers. The multiple obvious advantages of this approach are presented by the authors. I liked that they also gave some disadvantage of the solution. I believe layered architectures are great to tackle complexity in large complex system, but they add unnecessary complexity to simple systems. For example there is a lot of overhead if the lower layers need to perform expensive tasks not needed by the upper layers. Even though this is considered good software engineering practices, it should be determined just as with any other pattern if layered architecture is a good solution for the problem before using it.