Robert Martin's Clean Architecture proposes a strict separation of responsibilities that makes systems testable, maintainable and framework-independent. A look at its principles and concrete application.
Clean Architecture, formalized by Robert C. Martin (Uncle Bob), rests on a fundamental principle: dependencies point only inward. The business domain — entities and use cases — is at the center and depends on nothing external. Frameworks, databases, user interfaces are implementation details surrounding this core. You can change framework or database without touching business logic.
In practice for a Spring Boot application, this translates to four distinct layers:
- Domain — entities, value objects, pure business rules. No dependency toward the outside.
- Application — use cases, input and output ports. Orchestrates the domain without knowing the infrastructure.
- Infrastructure — JPA adapters, HTTP clients, configurations. Implements the outbound ports defined by the application layer.
- Presentation — REST controllers, DTOs. Adapts incoming requests into use case calls.
Dependencies never cross inward without going through interfaces (the ports).
Implementation reveals constant tension between architectural purity and pragmatism. For a simple CRUD, applying Clean Architecture is obvious over-engineering. For complex business logic with many rules and invariants, it's an investment that pays off quickly in testability and evolvability. The heuristic rule: if your use cases contain more than simple repository orchestration, Clean Architecture deserves consideration.
→ See also: Hexagonal Architecture (Ports & Adapters) · SOLID principles revisited · Domain-Driven Design