Clean Architecture
Concentric layers with dependencies pointing only inwards.
4 to work through
-
intermediate Multiple choice
A service calls a payment provider over HTTP. The provider occasionally returns 503 and occasionally times out. In a domain / application / adapter layering, which layer should own the retry and backoff policy?
3 min answer -
intermediate
A team adopts a layered architecture with strict dependency rules and finds every small change touches many files. Is the architecture wrong, or the application of it?
2 min answer -
intermediate
Review this design. Every repository method opens its own transaction and commits before returning. One use case calls four repositories and then publishes an event. Support reports occasional orders with a payment row and no shipment row. What would you change and what would you leave alone?
3 min answer -
advanced
When is clean architecture over-engineering, and what is the signal that you have its costs without its benefits?
2 min answer
2 terms in this topic
Clean Architecture
Concentric layers with dependencies pointing inward, so business rules know nothing about frameworks, databases or delivery mechanisms.
conceptDependency Rule
The constraint that source-code dependencies may point only inward, from detail toward policy, regardless of the direction of control flow.
Neighbouring topics
Software Architecture
General material on the engineering underneath an architecture.
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Refactoring
Changing structure without changing behaviour, in verified steps.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.