Ithaca: the Clean and Hexagonal Architectural Island

An introduction to Clean and Hexagonal Architecture principles:

Get ready to sail from the Scylla and Charybdis’s shores of 3-layered architecture to the safe Ithaca refreshing shores of Clean and Hexagonal Architecture! Brace yourself as we surf from zero to Ulysses (a hero!), leaving behind monstrous code and embracing cleanliness and modularity. No more Odysseys; protect your source code navigation through Clean and Hexagonal Architecture principles!

1. Ithaca
The Clean and Hexagonal Architectural Island

2. Luca Guadagnini
@lucaguada
https://www.cherrychain.it
Domain
Driven
Design

3. Our Odyssey
❖Book 1: What is software architecture?

❖Book 2: A common 3-layered approach

❖Book 3: A clean and hexagonal solution

❖Conclusions: Ithaca

4. What are we talking about, when we are talking about
Software Architecture?
oh com’on!
building
software is
easy!

5. Software elements for reasoning
Library
System call
Interface
File
Process
control
Cache
mechanism
User Interface
Library
Blocking I/O
driver

6. Software elements for reasoning
File
UI
System call
Interface
Library 1
Library 2
Process
control
Cache
mechanism
Blocking I/O
driver

7. The eye of the beholder stakeholder
Hi little architect, I’m your
stakeholder, is your
software good enough?
Nobody knows
Developers

8. What can I do to make my architecture nice?
Quality attributes:

●Availability
●Deployability
●Energy Efficiency
●Integrability
●Modifiability
●Performance
●Safety
●Security
●Testability
●Usability

9. What can I do to make my architecture nice?
Quality attributes:

●Availability
●Deployability
●Energy Efficiency
●Integrability
●Modifiability
●Performance
●Safety
●Security
●Testability
●Usability
We don’t
need to
cover
them all
Process guidelines:

●An architecture team and a CTO bound to developers

●Focus on a well-specified queue of QA’s

●Docs!

●Evaluated by QA

●From a walking-skeleton with no integrations to a
incrementally growing system

10. What can I do to make my architecture nice?
Quality attributes:

●Availability
●Deployability
●Energy Efficiency
●Integrability
●Modifiability
●Performance
●Safety
●Security
●Testability
●Usability
Structural guidelines:

●Functional modularization

●QA’s obtained with well-know architectural patterns

●Platform or tool independent

●Write and read sides segregation

●Design patterns are your friend (when you know the
problem you want to solve)We don’t
need to
cover
them all

11. A common architectural pattern: the 3-layered architecture
oh com’on!
my
architecture
is fine!

12. No really, how can I start?
3-layered architecture
Presentation
Business
Persistence

13. No really, how can I start?
3-layered architecture
Presentation
Business
Persistence
Process control
Blocking I/O
driver
User Interface
File
Scheduler
Request

14. Good enough?
Quality attributes:

●Deployability
●Modifiability
●Testability
n-layered architecture
Presentation
Business
Persistence
Web
Database

15. Good enough?
Quality attributes:

●Deployability
●Modifiability
●Testability
n-layered architecture
Web Presentation
Business
Persistence
Web HTTP/1.1
Database
Web HTTP/2.0
Mobile Presentation
Business

16. Simplest solution: The Ram-Runaway Pattern

17. What really matters?
n
m
-layered architecture
Presentation
Business
Persistence

18. How to be clean and hexagonal with an architecture
oh com’on!
it’s not done
yet?

19. Let’s start to be clean: Domain Entities
Domain
Entities

20. Let’s start to be clean: Use Cases
Use Cases
Domain
Entities

21. Let’s start to be clean: Services (i.e. Controllers, Gateways, etc…)
Use Cases
Domain
Entities
Controllers
Presenters
Gateways

22. Let’s start to be clean: External Services (i.e. Web, DB, UI, etc…)
Use Cases
Domain
Entities
Controllers
Presenters
Gateways
Web
UI
DB

23. Keep going hexagonal: Domain Model
User Interface Infrastructure
Domain Model

24. Keep going hexagonal: Domain Services
User Interface Infrastructure
Domain Services
Domain Model

25. Keep going hexagonal: Application Core
User Interface Infrastructure
Application Core
Domain Services
Domain Model

26. Keep going hexagonal: Requests from outside?
User Interface Infrastructure
Application Core
Domain Services
Domain Model

27. Keep going hexagonal: Ingress Ports and Adapters
User Interface
Infrastructure
Port
Port
Web Adapter
Terminal Adapter
Application Core
Domain Services
Domain Model

28. Keep going hexagonal: Egress Ports and Adapters
User Interface
Infrastructure
Port
Port
Web Adapter
Terminal Adapter
Port
Port
ORM Adapter
DB Adapter
Mail Adapter
Application Core
Domain Services
Domain Model

29. Keep going hexagonal: Slice and dice!
User Interface
Infrastructure
Port
Port
Web Adapter
Terminal Adapter
Port
Port
ORM Adapter
DB Adapter
Mail Adapter
Application Core
Domain Services
Domain Model
Component

30. Conclusions
Itacha!
at last!
What we learnt:

●Software architecture is not trivial

●Process and structural steps are essential

●Team communication is part of architectural tactics

●Business domain always rules

●Component isolations for the better

●Greek mythology is awesome

31. Conclusions
Itacha!
at last!
You can choose how to end the Odysseus you got in yourself:

●in homeric Odyssey the hero died by age

●in the tragedy Telegonia the hero is killed by his son

●in Odyssey written by Nikos Kazantzakis the hero started a new
journey of dreams and discoveries

●in Dante’s Inferno the hero died because he wanted to know too
much

●write your own story

32. Please Nobody, let
me know if
everything works!

33. References:

●Software Architecture in Practice
by Len Bass, Paul Clements, Rick Kazman

●Fundamentals of Software Architecture
by Mark Richards, Neal Ford

●Clean Architecture
by Robert C. Martin

●Get Your Hands Dirty on Clean Architecture
by Tom Hombergs

●Designing Hexagonal Architecture with Java
by Davi Vieira
Thanks
for
listening!