Architectural patterns => Mud to structure => layers.

Background -

We apply mud to structure when a large system requires decomposition.

If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first, group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer.

Actually, different issues/solutions are splinted into different abstract units. Second, after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers. 

If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern.

Layer architecture -

We can have many components in one layer. Layer N can talk to layer N + 1 directly but cannot talk to N + 2 or further down layers.

Scenarios of flow controls -

1. The flow control of request is, client-to-FirstLayer-to-LastLayer, and in same way, flow control of response is, LastLayer-to-FirstLayer-to-client.
2. Sometimes layer N + K (or say, some layer in-between first and last) can give you result, in that case, we can respond result from that the layer itself, no need to go till the last layer.
3. Intermediate layers shall behave dynamically, according to the nature of request.
4. Two stacks can also communicate with each other, like in networking two OSI models talk, one from sender ends and one from receiver ends.

Notes – most stable component (where business requirements don’t change rapidly) will be at the bottom level. In other words, user-visible component will be on top level, as we change them very frequently. Too few layers are not good, as they result in poor structure. Too many layers are also not good, as they will impact performance.

A very classic example of layer architecture pattern is OSI-7 layer model -

Benefits of layer architecture –

1. You can modify/improve any specific layer without bothering about other layers.
2. Any common layer (for example – communication or logging) can be taken into other software framework or application directly, without much modification. Or in other words, it will give you exchangeable parts. You can import and export any layer as per the condition.
3. Debugging will become easy, as now you can see till which layer control went fine and where it got stuck, and then fix it in less time frame.
4. Maintainability will be cheaper.
5. The understanding of whole system through small logical layers will be easy, so any new joiner will take less time to understand the product.
6. Component will not be tightly coupled.
7. Each layer represents a black box design.

Difficulty –

1. Difficult to set the correct level of granularity, while creating layers.
2. Identify the communication mechanism between layers, as sometimes different layer belongs to different tier.

Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.