Introduction to Clean Architecture
Separation of concerns by dividing the software into different layers
Use Dependency Inversion and Polymorphism to create a dependency rule to make the
domain layer most independent and stable layer
Source code dependencies can only point inward, towards to domain layer
Independent of Frameworks, UI, Databases and any external agency
Testable domain layer without requiring and external element
Define Entities and Use Cases for domain logic
Same high level principle with hexagonal and onion architectures: Isolate the domain
Hexagonal Architecture
Hexagonal Architecture also known as Ports & Adapters
Divides the software as insides and outsides, and start with inside, domain layer
The principle of the hexagonal architecture is to isolate the domain from any
dependency, such as UI, Data layer or even a framework like Spring
It is a response to the desire to create thoroughly testable applications with
isolated business logic from the infrastructure and data sources
Invented in 2005 by Alistair Cockburn
As Cockburn says: “Allow an application to equally be driven by users,
programs, automated test or batch scripts, and to be developed and tested in
isolation from its eventual run-time devices and databases.”
Advantages of Clean & Hexagonal Architectures
Layered Architecture
Especially useful for long-lasting applications that need to keep up with changing Presentation
requirements Layer
Improvement to traditional Layered Architecture. The dependencies are now Business Layer
plugins to the business logic. All dependency arrows point to business logic
making the domain independent. Reverses the relation using ports and adapters. Data Layer
Delay the implementation details of dependencies
Easier to test the business logic by mocking the dependencies even before
Clean Architecture
deciding the implementation details
Replace an adapter implementation easily, without touching the business logic
Easier to maintain as changing a part of software will not affect other parts
Independent development and deployment of different parts
Business Logic in Clean Architecture
Entities: Objects that embodies a small set of critical business rules
Use Cases: Describes application-specific business rules. Contains the
rules that specify how and when the Critical Business Rules within the
Entities are invoked.
Orchestrates 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
Clean Architecture and Domain Driven Design(DDD)
Same High level approach
Domain layer consists of: Domain layer consists of:
Entities Entities with an Aggregate root
Use Cases Domain services
Clean Architecture
“By separating the software into layers and conforming to the Dependency Rule,
you will create a system that is intrinsically testable, with all the benefits that implies.
When any of the external parts of the system become obsolete, such as the database,
or the web framework, you can replace those obsolete elements with a minimum of fuss”
“A shopping cart application with a good architecture will look like a shopping cart application.
The use cases of that system will be plainly visible within the structure of that system.
Developers will not have to hunt for behaviors, because those behaviors will be
first-class elements visible at the top level of the system”
“High-level modules should not depend on low-level modules. Both should depend on abstractions”
“Abstractions should not depend on details. Details should depend on abstractions”
“The way you keep software soft is to leave as many options open as possible,
for as long as possible. What are the options that we need to leave open?
They are the details that don’t matter.
The details are those things that are necessary to enable humans, other systems, and programmers to communicate with the policy,
but that do not impact the behaviour of the policy at all. They include IO devices, databases, web systems, servers, frameworks,
communication protocols, and so forth”
