Single responsibility principle
What changes for the same reason
should be grouped together
● All the things related to your framework
● All the things related to your domain model
● All the things related to your database
The most important distinction is...
Not too many groups
Domain vs Infrastructure
(entities, value objects)
● Use cases
● Interfaces for boundary
● Framework-specific code
● Implementations for
● Web controllers, CLI
By separating domain from infrastructure code you
automatically increase testablity
You can replace an adapter without
affecting the ports
You can postpone the choice for
database vendor, framework, ORM, etc.
You can more easily keep up with
the change rate of framework-specific code
Or replace the framework altogether...
● Alistair in the "Hexagone": https://www.youtube.com/watch?v=th4AgBcrEHA
● My upcoming book "Advanced Web Application Architecture"
● Nat Pryce, Steve Freeman - Growing Object-Oriented Software, Guided by Tests
● Vaughn Vernon - Implementing Domain-Driven Design (see the chapter about