Layered Architecture: The Default Pattern, Its Sinkhole Trap, and When to Evolve

1. What Is Layered Architecture?

Layered architecture is the most common architectural style. It organizes code into horizontal layers by technical responsibility rather than business domain. The standard four-layer model from top to bottom is:

Presentation layer — handles all user interface and browser communication logic.

Business layer — executes specific business rules related to the request.

Persistence layer — responsible for data persistence.

Database layer — physical database or file system that stores data.

Classic examples include Spring MVC applications with Controller, Service, and DAO layers.

2. Closed vs. Open Layers and the Architecture Sinkhole

A closed layer means requests must pass through it sequentially and cannot be skipped. An open layer allows requests to bypass it and access lower layers directly.

While closed layers help isolate change impact, making all layers closed can create the architecture sinkhole anti-pattern: a simple request passes through every layer with each layer doing no real work — only wrapping and forwarding — wasting CPU and memory.

Opening layers can be useful. For example, if the business layer contains many shared components that the presentation layer should not use directly, but the presentation layer still needs to call the business layer, one solution is to insert a service layer between business and persistence, concentrate shared components there, mark the business layer as closed, and mark the service layer as open. Each decision to open or close a layer is an architectural decision.

3. Characteristic Scoring

Overall cost and simplicity are the main advantages of layered architecture.

3.1 Suitable Scenarios

Small, simple applications or websites.

Situations with tight budget and time constraints — a good starting point.

When architects are still evaluating whether a more complex architecture is warranted but development must begin.

Guidance: Keep code reuse to a minimum and keep object hierarchies relatively shallow to maintain good modularity, which will help later migration to other architectural styles.

3.2 Unsuitable Scenarios

As systems built with layered architecture grow, maintainability, testability, and deployability degrade severely. Large systems are better served by more modular architectural styles.

4. Team Topology

Layered architecture is independent of team topology and works with any team configuration:

Stream-aligned teams — layered architecture often represents a complete system flow, allowing a team to own the end-to-end workflow from presentation to persistence.

Enabling teams — highly modularized by technical concern, enabling teams can experiment on a single layer without affecting others.

Complicated-subsystem teams — each layer performs a very specific task, so this style works well with complicated-subsystem team topology.

Platform teams — can leverage many off-the-shelf tools, but the main challenge mirrors the general monolith problem: as the platform grows, it becomes increasingly unwieldy.

1. Fundamentals of Software Architecture 2nd Chapter 10 ↩︎