Ithaca: the Clean and Hexagonal Architectural Island

Ithaca
The Clean and Hexagonal Architectural Island

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

Our Odyssey
❖ Book 1: What is software architecture?
❖ Book 2: A common 3-layered approach
❖ Book 3: A clean and hexagonal solution
❖ Conclusions: Ithaca

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

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

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

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

What can I do to make my architecture nice?
Quality attributes:
● Availability
● Deployability
● Energy Efficiency
● Integrability
● Modiﬁability
● Performance
● Safety
● Security
● Testability
● Usability

Quality attributes:
● Availability
● Deployability
● Integrability
● Modiﬁability
● 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-speciﬁed queue of QA’s
● Docs!
● Evaluated by QA
● From a walking-skeleton with no integrations to a
incrementally growing system

Quality attributes:
● Availability
● Deployability
● Integrability
● Modiﬁability
● 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

A common architectural pattern: the 3-layered architecture
oh com’on!
my
architecture
is ﬁne!

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

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

Good enough?
Quality attributes:
● Deployability
● Modiﬁability
● Testability
n-layered architecture
Presentation
Business
Persistence
Web
Database

Good enough?
Quality attributes:
● Deployability
● Modiﬁability
● Testability
n-layered architecture
Web Presentation
Business
Persistence
Web HTTP/1.1
Database
Web HTTP/2.0
Mobile Presentation
Business

Simplest solution: The Ram-Runaway Pattern

What really matters?
nm
-layered architecture
Presentation
Business
Persistence

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

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

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

Let’s start to be clean: Services (i.e. Controllers, Gateways, etc…)
Use Cases
Domain
Entities
Controllers
P
r
e
s
e
n
t
e
r
s
G
a
t
e
w
a
y
s

Let’s start to be clean: External Services (i.e. Web, DB, UI, etc…)
Use Cases
Domain
Entities
Controllers
P
r
e
s
e
n
t
e
r
s
G
a
t
e
w
a
y
s
Web
U
I
D
B

Keep going hexagonal: Domain Model
User Interface Infrastructure
Domain Model

Keep going hexagonal: Domain Services
Domain Services
Domain Model

Keep going hexagonal: Application Core
Application Core
Domain Services
Domain Model

Keep going hexagonal: Requests from outside?
Application Core
Domain Services
Domain Model

Keep going hexagonal: Ingress Ports and Adapters
P
o
r
t
P
o
r
t
W
e
b
A
d
a
p
t
e
r
T
e
r
m
i
n
a
l
A
d
a
p
t
e
r
Application Core
Domain Services
Domain Model

Keep going hexagonal: Egress Ports and Adapters
P
o
r
t
P
o
r
t
W
e
b
A
d
a
p
t
e
r
T
e
r
m
i
n
a
l
A
d
a
p
t
e
r
P
o
r
t
P
o
r
t
O
R
M
A
d
a
p
t
e
r
DB Adapter
M
a
i
l
A
d
a
p
t
e
r
Application Core
Domain Services
Domain Model

Keep going hexagonal: Slice and dice!
P
o
r
t
P
o
r
t
W
e
b
A
d
a
p
t
e
r
T
e
r
m
i
n
a
l
A
d
a
p
t
e
r
P
o
r
t
P
o
r
t
O
R
M
A
d
a
p
t
e
r
DB Adapter
M
a
i
l
A
d
a
p
t
e
r
Application Core
Domain Services
Domain Model
Component

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

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

Please Nobody, let
me know if
everything works!

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!

Ithaca: the Clean and Hexagonal Architectural Island

More Related Content

Similar to Ithaca: the Clean and Hexagonal Architectural Island

Recently uploaded

Ithaca: the Clean and Hexagonal Architectural Island