Clean Architecture
Overview
Clean architecture separates business rules from frameworks, infrastructure, and UI details.
Why It Matters
The benefit is easier change when external technology moves faster than the domain logic.
Core Concepts
- Inner layers should not depend on outer layers.
- Policies should outlive implementation details.
- Boundaries should be explicit.
Mental Models
Use clean architecture when the domain is worth protecting from churn.
Best Practices
- Keep domain logic isolated.
- Translate external input at the boundary.
- Do not force every project into the same shape.
Common Mistakes
- Applying the pattern to trivial apps.
- Creating layers with no real separation.
- Making the code harder to navigate than the problem requires.
Trade-offs
This style can improve longevity, but it adds ceremony. The cost only makes sense when the domain is stable and valuable.
Decision Framework
| Question | If yes | If no |
|---|---|---|
| Is the domain complex? | Consider clean boundaries | Keep it simpler |
| Do dependencies change often? | Isolate them | Avoid extra layers |
Examples
- Keep pricing rules out of React components.
- Convert API input into domain objects at the boundary.
Checklists
- Are policies separated from frameworks?
- Is the domain easy to test?
- Is the extra structure buying real stability?
Senior Engineer Notes
Senior engineers use clean architecture selectively. The goal is lower change cost, not architectural purity.