Clean Architecture vs Layered (N-tier) Architecture
Fast recall
Quick revision
Core answer
Direction of dependencies, where the framework lives, why Clean Architecture protects the domain, and the trade-offs at different project sizes.
Saying 'Clean Architecture is just layered with extra interfaces' — the dependency direction is fundamentally different.
Discuss migration paths, when to graduate, multi-input adapter benefit, and the relationship to Hexagonal/Onion.
Interview-ready guide
Interview answer
Two mental models
Layered: stack of horizontal slices. Controller → Service → Repository → Database. Dependencies flow downward. DB at the base. Domain depends on JPA/framework. Whole app built around the database. Most popular Spring Boot pattern.
Clean Architecture: concentric circles, domain-centric. Frameworks (outer) → Interface Adapters → Use Cases → Entities (inner). Dependencies flow inward. Domain at center, framework on outside. DB is one of many possible adapters.
Same use case in both
Layered: @Service with @Autowired OrderRepository (Spring Data interface). Returns OrderEntity (@Entity). Domain coupled to JPA.
Clean: PlaceOrderInteractor in inner layer, plain Java, depends on OrderRepository port. Domain Order is a record. JpaOrderRepository in adapter layer implements the port, converts between domain Order and JPA entity.
What Clean adds
- Framework independence: no @Entity, @Transactional in inner circles. Swap Spring → Quarkus, JPA → Mongo — inner layers don't change
- Pure-unit testability: plain JUnit + in-memory port; no @SpringBootTest, no Testcontainers. Milliseconds
- Multiple input adapters share business logic: HTTP + Kafka + CRON all call PlaceOrderUseCase
- Explicit boundaries: ports document what the core needs
- Migration safety: replace Postgres with Mongo = replace adapter; domain logic + tests untouched
What layered keeps cheaper
- Less code: fewer interfaces, mappers, packages. For 5-endpoint CRUD, half the lines
- Familiarity: Spring tutorials default to layered
- Direct framework leverage: Spring Data magic methods at the service
- Faster prototyping: POC ships in hours
When to choose which
Layered: CRUD-heavy thin business logic, one input adapter, small team/service, speed > flexibility, team comfortable with Spring conventions.
Clean: rich domain logic, multiple input adapters share use cases, testability without infrastructure required, long-lived service, pairing with DDD.
Migration path layered → Clean
- 1Extract use case interfaces from services
- 2Move pure domain logic into framework-free classes
- 3Define repository ports; existing Spring Data interfaces become JpaXxxRepository, adapter implements port
- 4Mappers (DTO ↔ domain, JPA entity ↔ domain) into adapter packages
- 5Add unit tests with in-memory ports
- 6Repeat per bounded context
Common mistakes
- Calling layered-with-interfaces 'Clean' — only Clean if core defines the contract
- Clean as gospel for tiny services — 4 endpoints don't need 12 use cases
- Spring annotations leaking inward — @Service on use case, @Entity on domain object
- Duplicating domain and JPA entities dogmatically — sometimes one record works for both
- Thinking Clean is anti-Spring — Spring lives in adapters and wires the core
- One port per repository method — group cohesive behavior
Recommendation
Default to layered for CRUD-heavy Spring Boot services where business logic is thin, the team is small, and time-to-prototype matters. Reach for Clean Architecture (or Hexagonal — same family) when the domain is rich, multiple input adapters share use cases, fast pure-unit testing of business logic is critical, or you're pairing with DDD. The two are not enemies — Clean still uses Spring; Spring just lives in the adapters, not the core. Migrate incrementally one bounded context at a time, never as a big-bang rewrite.
Clean Architecture vs Layered (N-tier) Architecture
Direct Answer
Layered architecture organizes code in horizontal stacks (controller → service → repository → DB) where each layer depends on the layer below, and the DB sits at the foundation — the whole app is built around the database. Clean Architecture organizes code in concentric circles with the domain at the center and dependencies pointing only inward — the DB is just one of many adapters on the outside, and the domain depends on nothing. Layered is simpler and ubiquitous; Clean Architecture isolates business logic from frameworks and gives you pure-unit testability and easy adapter swaps.
Common Mistakes & Pitfalls
Saying 'Clean Architecture is just layered with extra interfaces' — the dependency direction is fundamentally different.
Check your understanding
Answer these without looking back at the article.
- How do you incrementally migrate a layered Spring Boot app to Clean Architecture?
- What's the relationship between Clean Architecture and Hexagonal Architecture?
- When would you regret using Clean Architecture?
- How do transactions work in Clean Architecture without polluting the inner layers with @Transactional?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.