Scribd
Upload
106 views

Clean and Hexagonal Architecture-SHARE

The document introduces the concepts of Clean Architecture and Hexagonal Architecture. Both aim to isolate the domain layer from external dependencies like the UI, databases, frameworks. This is done by defining layers/ports and having dependencies point inward towards the domain. This makes the domain highly independent and testable without external elements. The domain logic is defined through entities and use cases. The architectures allow flexible replacement of external parts without impacting the core business logic.

Uploaded by

Jean Semolini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
106 views

Clean and Hexagonal Architecture-SHARE

The document introduces the concepts of Clean Architecture and Hexagonal Architecture. Both aim to isolate the domain layer from external dependencies like the UI, databases, frameworks. This is done by defining layers/ports and having dependencies point inward towards the domain. This makes the domain highly independent and testable without external elements. The domain logic is defined through entities and use cases. The architectures allow flexible replacement of external parts without impacting the core business logic.

Uploaded by

Jean Semolini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 6

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”

You might also like