Why Layered Monoliths Still Matter: From 4‑Layer to Modular 5‑Layer Architecture

1. Classic Four‑Layer Monolithic Architecture

The classic four‑layer monolithic architecture divides an application into Presentation, Business, Persistence, and Data Storage layers, each with distinct responsibilities:

Presentation layer: Displays information to end users and captures input that triggers business logic.

Business layer: Implements core business logic.

Persistence layer: Handles data access.

Data storage layer: Underlying storage infrastructure.

This style is familiar to many developers. Its key characteristics are:

Strict top‑down dependencies; each layer must be traversed for data flow.

Clear separation of concerns: each layer focuses only on its own responsibilities.

In addition to concern separation, layers also isolate change: lower layers change slowly, upper layers change quickly, reducing the impact of low‑level modifications on higher layers.

1.2 Five‑Layer Monolithic Architecture

The four‑layer model faces two main issues:

Inter‑layer data efficiency problems due to strict call constraints.

Limited reuse of services within the business layer.

To improve reuse, a five‑layer architecture introduces a General Service layer that consolidates shared services, allowing the business layer to call lower layers directly when needed.

Advantages over the four‑layer approach include better reuse through the intermediate layer, but drawbacks appear:

Added layer reduces data transmission efficiency and raises implementation cost.

Open General Service layer can lead to uncontrolled cross‑layer calls, increasing system complexity and cognitive load.

2. Common Issues in Monolithic Layered Architecture

Despite its popularity, many developers misunderstand layering, treating it as a default choice without considering its true purpose: managing complexity by abstracting responsibilities and controlling change propagation.

2.1 Impact on System Complexity and Efficiency

Layers with different change rates mean upper layers evolve quickly while lower layers remain stable. More layers clarify dependencies but increase call chain length and data transformation overhead.

Strict layering improves clarity but may hinder performance; allowing cross‑layer calls can reduce transformation cost but introduces inconsistency and harder governance.

2.2 Change Isolation

Layering is often assumed to fully isolate changes (e.g., swapping a database or ORM). In practice, isolation only works when layers depend on abstractions, not concrete implementations, and even then changes can ripple upward.

2.3 Gap Between Problem Domain and Solution

Layered monoliths separate concerns from a technical perspective, not a business‑domain perspective. For example, an "Order" component is scattered across Controller, Service, and DAO layers, increasing cognitive cost when navigating the codebase.

Applying component‑oriented thinking to monolithic layering leads to a modular monolith, where modules are organized by business domain rather than technical tier, facilitating clearer interfaces and smoother migration to microservices.

3. Conclusion

Layered monolithic architecture applies the layering concept to monoliths, focusing on technical responsibility separation and change control. However, this technical focus creates a gap between problem domain and implementation, raising system cognitive complexity. Introducing modular thinking aligns layers with business domains, reducing this gap and providing a solid foundation for future microservice decomposition.