Clean Architecture
Clean Architecture organizes software so that business rules sit at the center, independent of frameworks, databases, and delivery mechanisms. Dependencies point inward, making the core logic testable and replaceable without rewriting the surrounding infrastructure.
itSoftware engineering | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic - Clean Architecture
Clean Architecture is the subject of this course. Clean Architecture keeps business rules separate from delivery and infrastructure details. Your application still uses a web framework, database, message broker, or command line.
The useful unit of work is a closed loop: clarify the goal and boundaries, gather the inputs the practice requires, make the decision or change, record evidence, and return with owners for the next cycle. Skipping any link leaves teams busy without durable results.
Tooling supports the loop; it does not replace it. Choose tools after the boundary and evidence model are clear. Comparing products without that model produces feature matrices that do not change how the work runs.
Common failure modes include undefined ownership, metrics that count activity instead of outcomes, and irreversible steps taken without a review path. Treat those as design defects in the practice, not as individual heroics to compensate later.
Operators should be able to explain which signals would change a decision this week. If no signal can change the plan, the practice has become ritual. Keep the feedback path short enough that evidence still influences the next cycle.
Name the owners for each stage of the loop before the work scales. Unowned stages become permanent exceptions. Record decisions with enough context that a future operator can tell why a tradeoff was accepted. Prefer fewer, sharper metrics that change behavior over broad dashboards that only describe activity after the fact.
Read the Intro for the core model. Use the Cheatsheet when you need the operating map. Updates tracks official guidance when this course configures an update source; otherwise the practice is settled without a live feed.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Supports
- Separation of concerns, framework independence, testability, and independence from user interface, database, and external agencies
- The Dependency Rule, entities, use cases, interface adapters, frameworks and drivers, and boundary crossing through dependency inversion
- https://blog.cleancoder.com/uncle-bob/2011/11/22/Clean-Architecture.html
Supports
- Controller, interactor, presenter, and simple boundary-data flow
- Testing application policy without a web server, container, or user interface
- https://alistair.cockburn.us/hexagonal-architecture
Supports
- Original Ports and Adapters intent, terminology, inside-outside boundary, and multiple adapters per port
- Isolation from user-interface and database technology for testing and alternate application drivers
- https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
Supports
- Organizing architecture around use cases and business purpose instead of frameworks
- Deferring choices about frameworks, databases, web servers, and delivery mechanisms
- https://martinfowler.com/bliki/PresentationDomainDataLayering.html
Supports
- Logical layers as modules rather than physical tiers
- Domain independence from data sources, layering granularity, and domain-oriented modules for larger applications
- https://martinfowler.com/eaaCatalog/dataMapper.html
Supports
- Mapping between in-memory objects and database data while isolating both representations
- Keeping domain code unaware of database schema and mapping machinery
- https://www.pearson.com/en-us/subject-catalog/p/clean-architecture-a-craftsmans-guide-to-software-structure-and-design/P200000009528/9780134494326
Supports
- Book authorship, publication identity, scope, and official table of contents
- Coverage of design principles, components, boundaries, business rules, testing, frameworks, databases, and case studies
