Clean Architecture
Augustinas Nomicas
.NET Developer
What is good software architecture?
● Good architecture must be time-proof
● Architecture must change because of new business requirements,
not because of new technologies
● Good architecture must clearly communicate code purpose
● Being flexible in wrong places is bad example of software architecture
● Good architecture let's defer major decisions
Problem:
so many bad architecture
projects in the wild
Case study for market leading software
Why?
● Accumulated technical dept
● Bad software design
The goal of software architecture is to minimize the human effort
required to build and maintain the required system
Robert C. Martin
Aka Uncle Bob
Clean architecture
● Architectural style suitable for all platforms, languages and domains
● Abstract, more like “mindset” instead of concrete rules / frameworks
● Easily adoptable
Clean architecture
● Easily testable
● Independent from database
● Independent from frameworks
● Always ready to deploy
● High isolation of modules
Clean architecture is not always
right for small projects
So...
???
The center of your application is not the
database. Nor is it one or more of the
frameworks you may be using. The center
of your application is the use cases of your
application - Uncle Bob
Insurance company example
● The heart of insurance company business is insurance calculation
formula which would determine correct price for insurance policy
and ensure profitable business model
○ Insurance calculation can be performed by human being with peace of paper and
calculator
○ It’s the Critical Business Rule, and can be delivered to customer via
Fax/Mail/Mobile App/Web
What is use-case ?
Wikipedia:
a use case is a list of actions or event steps typically defining the interactions
between a role (known in the Unified Modeling Language as an actor) and a
system to achieve a goal.
Clean Architecture book:
These use cases orchestrate the flow of data to and from the entities, and
direct those entities to use their Critical Business Rules to achieve the goals of
the use case.
Two cases of business rules
● Business specific business rules
○ Fundamental business rules
● Application specific business rules
○ For example communication with user, validation
It’s important to separate those rules in application architecture
Software dependency
● In clean architecture we INVERT software dependencies for
○ Database
○ Framework
○ UI
How to invert dependency
References
AddCar CarSqlDB AddCar CarSqlDB
References
Business Database Business Database
layer layer layer layer
Implements
ICarStore
Entities
● Represent your domain model
● Entities should be reusable in many
applications
● They encapsulate the most general/high-level
rules.
Entities
● Entity layer must contain only POCO (Plain old
CLR object) objects
○ Easy to migrate between different .NET versions
○ Easy serialization and caching
○ Easy testable
Use Cases
● Use cases are application specific business
rules
○ Changes should not impact the Entities
○ Changes should not be impacted by infrastructure such
as a database
● Orchestrate data flow from and to Entities
● Validators, exceptions, commands, queries and
interfaces
Controllers / Gateways / Presenters
● Layer where 3rd party code can be used
○ MVC, API controllers, presenters, all belong here
○ Entity Framework: DbContext, Migrations,
Configurations
● Implements interfaces defined in Use-Cases
level
● No code further in (use cases, entities) should
have any knowledge of the db
DB / Devices / WEB / UI
● OS functions, api clients, file system, GPIO
● Web Server, SQL Server, Redis cache
● You’re not writing much of this code, i.e. we use
SQL Server, but we don’t write it.
● These are the glue that hook the various layers
up (IoC container XML config)
Only 4 circles?
● No, the circles are schematic. You may find that you need more than
just these four.
● BUT: Dependency Rule always applies. Source code dependencies
always point inwards.
● As you move inwards the software grows more abstract, and
encapsulates higher level policies. The innermost circle is the most
general and most stable
● Layers can not skip layers
Crossing boundaries
● Data that can cross boundaries are only simple data structures
● They are called DTOs, ViewModels
● You can not pass database rows or whole entities
● Passed data structure must be most convenient for inner circle
Main component
● Every system has “main” component where everything is wired-up
● It mostly likely has references to all layers
● Usually it is IoC container register
● Application.Startup method
Screaming architecture
The architecture should scream the intent of the system!
VS
Clean Architecture in ASP.NET MVC 5
Author: Matthew Renze
https://www.matthewrenze.com/articles/clean-architecture-in-asp-net-mvc-5/
Screaming architecture
● Architecture based on use-cases and shows them on the first glance
● Same functionality put under same folders and easy to find (high
cohesion)
What about .NET
Framework?
What about MVC?
● MVC is not an architecture
○ MVC was introduced in 1970s into Smalltalk
○ Intention was to use for small UI object (button, text input, circle)
○ MVC is a delivery design pattern
○ Should be in Presentation layer
What about testing?
● Clean architecture is very test-friendly
○ We can test our Entities and Use-cases (business logic) without database and UI
○ Test should be considered as outermost circle in the architecture
● Tests should be considered as first-class citizen of software
architecture
ASP.NET Examples
ASP.NET project template
https://marketplace.visualstudio.com/items?itemName=
GregTrevellick.CleanArchitecture
Northwind Traders in ASP .NET Core
https://github.com/JasonGT/NorthwindTraders
Clean Architecture with ASP.NET Core
https://www.youtube.com/watch?v=_lwCVE_
XgqI
Clean architecture
♡
KISS
Summary
● Business operations (use cases) are the most important thing!
Respect them and don’t pollute them with unnecessary things
● Database is only a Detail
● Frameworks are only the Details
● UI (Presentation) is a Detail
More By Robert C. Martin (Uncle Bob)
Ačiū!
