Notebook
Clean Architecture
Keeping business rules ignorant of the frameworks that ship them.
A codebase can be well-factored and still be married to its framework. Robert C. Martin’s Clean Architecture names the divorce: business rules sit in circles that know nothing about the web, the database, or whatever delivers them to a user. Hexagonal, Onion, and Screaming Architecture reach the same place by different roads. Martin’s diagram was an attempt to draw the one idea underneath all three.
This notebook follows that idea from the rule that makes it work through to the payoff it buys you. The examples come from eShopOnWeb, the reference app Steve “Ardalis” Smith built to demonstrate the architecture in ASP.NET Core, originally for Microsoft and now community-maintained at NimblePros.
Start at The Dependency Rule.
In this notebook
- The Dependency RuleSource code dependencies point in one direction, and the compiler can prove it.
- EntitiesBusiness rules a change of framework, UI, or database has no reason to touch.
- Use CasesOrchestrating entities to do one specific job, and nothing about how that job gets triggered.
- Interface AdaptersWhere a controller, a presenter, and a database row are all translations of the same use case.
- Frameworks & DriversThe web, the database, and the framework — kept as details, not as the architecture.
- Crossing BoundariesCalling outward without a source-code dependency pointing outward — the trick behind the rule.
- Screaming ArchitectureA codebase that announces what it does before it announces what it runs on.
- Testing Without FrameworksThe payoff for the rule — business logic tested with no web server, database, or UI in the room.