My notes on layered architecture

Layered application architecture has been popular since the days of three-tiered architecture. In this article I want to highlight some areas of concern in this architecture style when building for, or migrating to, cloud-native applications.

Briefly, layered architecture advocates for decomposing an application into the following tiers: Persistence, Service, and Presentation as shown above in Figure 1. Many organizations have team hierarchies around these layers, giving credence to Conway's law.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

Persistence layer deals with data access, mainly owned by DBA teams. Service layer deals with application business rules and constraints. These are mainly core Dev teams. Presentation layer deals with UI. Front End Dev teams own this space.

Observe that these tiers are purely around technical concerns and have not much to do with business domain. Like myself you may have came across this architecture style in many diverse domains such as Financial, Healthcare, Insurance, Communication, etc.

In cloud-native applications, we are looking for some key features such as team autonomy, independent deployability, time to market, scalability, etc. Let's see how a change is propagated through a layered architecture. In the following diagram, relevant changes for a new feature are represented by a star in each of the corresponding layers.

This shows a high degree of coupling among the layers. These dependencies mean that a customer will not see the new feature till it is complete in all the layers. This is a classic side effect of a monolithic application. Team autonomy is absent as there is a dependency on the downstream teams. It needs to be deployed (and rolled back in case of last minute production issues) as one unit. It delays time to market. Horizontal scalability (or scaling out) is difficult to achieve.

For an alternative approach, we first have to stop thinking in terms of technical boundaries and think more along the lines of business or domain boundaries. This idea is advocated by Domain-Driven Design (DDD). Event Storming is a useful approach to carve out these domain boundaries. These domain concerns cut across all the layers of the application, shown by the vertical boundaries in the following diagram.

Decomposing an application along domain boundaries require a different way of thinking. By Conway's law, we have to organize our teams around these boundaries as well. In other words, for each domain boundary a team owns presentation, service, and persistence aspects of the domain. In the end, we are left with the following architecture. Note that one could think of each vertical slice as an independent cloud-native application or a microservice.

We started with a monolithic three-tiered application. Using Domain-Driven Design, we decomposed it around business or domain boundaries. Each domain boundary became an independent cloud native application or a microservice. Communication among these microservices is via a well defined contract or API. As the above diagram shows, there is no code sharing among the microservices. Similarly, microservices do not share the persistence layer. In this final state we have decomposed our application in such a way that allows for team autonomy. This lends itself well for independent deployability. Horizontal scalability is in-tact. With decomposition along domain boundaries, our architecture is loosely coupled and highly cohesive. As an added bonus, each domain team can pick persistence technology, service framework, and presentation library that best fits the team.

In summary, traditional layered architecture uses horizontal layering along technical concerns. Business or domain considerations are lumped together in each layer. If careful attention is not paid to modularity, it could result in Big Ball of Mud (BBM). Decomposing such an application into independent microservices will result in a distributed monolithic application. First step for cloud native architecture is to think application decomposition along business or domain boundaries. Following Domain-Driven Design approach would result in a distributed application that is loosely coupled and highly cohesive.