Hexagonal architecture (a.k.a. Ports and Adapters) is a fabulous pattern that has more advantages than the ones for which it has been originally created. One can think in an orthodox vision that patterns do not evolve. That it is important to keep Alistair Cockburn’s pattern like it was described back in the days. One can think that some patterns may evolve, that Hexagonal Architecture has more facets than we think. This session will present both the original pattern in detail, and some alternative versions (related to Domain Driven Design). Session made at Socrates Soltau 2022 https://www.socrates-conference.de/foundations

1. Hexagonal
Architecture
& Beyond
Thomas PIERRAIN
(use case driven)
@tpierrain

2. Hexagonal
Architecture
& Beyond
building software since 25 years
eXtreme Programmer now dealing with people after
12 years of architecture and change management
currently VP of Engineering @ Agicap in Lyon (scale up)
XP, TDD, DDD, Event Sourcing,
Tech architecture, Reactive Programming
DDD FR organizer
Thomas PIERRAIN (use case driven)

3. MENU
1.ORIGINAL
PATTERN
2. ALTERNATE
TAKES
(DDD FRIENDLY)

4. MENU
2. ALTERNATE
TAKES
(DDD FRIENDLY)
1.ORIGINAL
PATTERN

5. HEXAGONAL ARCHITECTURE: ORIGINS
• SMALLTALK PROJECT (MID 90s): To be able
to work 2 weeks without the database
• WEATHER WARNING SYSTEM: To be able to
connect to multiple external systems (http,
telemetry, phone, RSS, db) without changing the
whole software every time
Alistair
Cockburn

6. HEXAGONAL ARCHITECTURE:
ONE PATTERN TO…
Alistair
Cockburn

7. HEXAGONAL ARCHITECTURE:
ACTUALLY, ONE PATTERN TO…
• Easily switch one technology with another without breaking our core
domain code (like plug-ins)
• Easily develop and test an application in isolation from its eventual run-
time devices and databases
• Have good time to market and fast feedbacks about what is really at stakes
for our users
Alistair
Cockburn

8. 2 ZONES
DOMAIN
INFRA

9. COMMUNICATING VIA…

10. DOMAIN
PORTS & ADAPTERS
PORTS IN THE
DOMAIN

11. DOMAIN
INFRASTRUCTURE
(in proc)
PORTS & ADAPTERS
PORTS IN THE
DOMAIN
ADAPTERS IN
THE INFRA

12. DEPENDENCIES ALWAYS TOWARDS THE INSIDE
DOMAIN
DEPENDENCY INVERSION PRINCIPLE
A.K.A. CONFIGURABLE DEPENDENCIES
INFRA

13. DEEPLY ASYMMETRICAL
LEFT-SIDE
(PRIMARY)
(DRIVER)
RIGHT-SIDE
(SECONDARY)
(DRIVEN)
👻
USER
DATA STORES
EXTERNAL
SYSTEMS
APIS

14. “implements”
DOMAIN
INFRASTRUCTURE
« uses »
DEEPLY ASYMMETRICAL
LEFT-SIDE PORTS
« uses »
« uses »
“use”
RIGHT-SIDE ADAPTERS
RIGHT-SIDE PORTS
“implemented by”

15. “implements”
DOMAIN
INFRASTRUCTURE
« uses »
DEEPLY ASYMMETRICAL
LEFT-SIDE PORTS
TO ENTER OUR DOMAIN
LEFT-SIDE ADAPTERS
TRANSLATE
TECH TO DOMAIN
RIGHT-SIDE ADAPTERS
TRANSLATE DOMAIN TO
TECH
RIGHT-SIDE PORTS FOR
OUR DOMAIN TO
INTERACT WITH OTHERS
« uses »
« uses »
“use”
“implemented by”

16. PORTS ARE CONTRACTS
LEFT-SIDE PORTS
ARE DOMAIN-
DRIVEN
CONTRACTS FOR
OTHERS TO
INTERACT WITH US
DOMAIN
INFRASTRUCTURE
« uses »
RIGHT-SIDE PORTS
ARE DOMAIN-
DRIVEN
CONTRACTS FOR
US TO ASK
SOMETHING TO
SOMEONE ELSE

17. HEXAGONAL “MICRO” SERVICES
@tpierrain (use case driven)
AUDITORIUM
SEATINGS API
SEAT SUGGESTIONS DOMAIN
INFRASTRUCTURE
HTTP
SUGGESTIONS
DB
SEAT SUGGESTIONS API
(in proc)
HTTP

18. HEXAGONAL ARCHITECTURE
IN MOTION

19. OUR DOMAIN

20. SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

21. SEATS SUGGESTIONS API
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

22. AUDITORIUM SEATING
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

23. AUDITORIUM SEATING
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

24. AUDITORIUM SEATING
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

25. AUDITORIUM SEATING
API
SEATS AVAILABILITY
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
“I also need to know
which seats are
already reserved for
show Z”
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

26. AUDITORIUM SEATING
API
SEATS AVAILABILITY
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
“I also need to know
which seats are
already reserved for
show Z”
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

27. AUDITORIUM SEATING
API
SEATS AVAILABILITY
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
“I also need to know
which seats are
already reserved for
show Z”
OUR CORE DOMAIN
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

28. AUDITORIUM SEATING
API
SEATS AVAILABILITY
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
“I also need to know
which seats are
already reserved for
show Z”
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

29. AUDITORIUM SEATING
API
SEATS AVAILABILITY
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
“I also need to know
which seats are
already reserved for
show Z”
“Ok. You can have seats
A1, A2, A3 in pricing tier 1,
C4, C5, C6 in pricing tier 2
…”
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

30. AUDITORIUM SEATING
API
SEATS AVAILABILITY
API
“I need the
auditorium seating
of show Z”
SEATS SUGGESTIONS API
“I also need to know
which seats are
already reserved for
show Z”
“Ok. You can have seats
A1, A2, A3 in pricing tier 1,
C4, C5, C6 in pricing tier 2
…”
SUGGESTING SEATS IN THEATERS
“What seats can you suggest for 3
people wishing to attend the show Z?”

39. LET’S SEE SOME CODE

40. HEXAGONAL ARCHITECTURE
MAIN CHALLENGES
• UNDERSTAND THE LEFT/RIGHT ASYMMETRY
• PORTS SHOULD “EXPRESS” DOMAIN CONCEPTS ONLY
• TESTS ARE KIND OF ADAPTERS

42. MENU
1.ORIGINAL
PATTERN
2. ALTERNATE
TAKES
(DDD FRIENDLY)

43. 2. ORIGINAL
PATTERN
MENU
2. ALTERNATE
TAKES
(DDD FRIENDLY)

44. OTHER INTENTS #1
• To properly split and protect our domain code from the infrastructure
one
community

45. OTHER INTENTS #2
• To reduce layering and complexity of our “baklava” architectures
community

46. OTHER INTENTS #3
• To postpone architecture decision at the right time (when we
understand the domain & our constraints)
community

47. OTHER INTENTS #4
• To modularize a monolith and get ready for a physical split among
various components/apis/μ services
community

48. AUDITORIUM
LAYOUTS DOMAIN
INFRA
DB
THE HIVE - MODULAR MONOLITH WITH “HEXAGONS” INSIDE
AUDITORIUM
SEATINGS DOMAIN
INFRA
DB
REPOSITORY
(ADAPTER)
SEATS AVAILABILITY
DOMAIN
INFRA
DB
In-Proc
@tpierrain (use case driven) 2.2
SEAT SUGGESTIONS DOMAIN
DB
INFRA
HTTP
In-Proc
In-Proc
SUGGESTI0NS
WEBCONTROLLER
(ADAPTER)
AUDITORIUMSEATINGS
WEBCONTROLLER
(ADAPTER)
INFRA
HTTP
The whole hexagons are
assembled in the same
process.
We are using
“lightweight” & In-Proc
driven adapters that are
making direct memory
calls towards other
hexagons' driver ports
(i.e. driven adapters
calling someone else’s
driver ports).
Modularized monoliths
are very handy for any
refactoring phase.

49. AUDITORIUM
LAYOUTS DOMAIN
INFRA
DB
SEAT SUGGESTIONS DOMAIN
INFRASTRUCTURE
HTTP
THE SPLIT - “MICRO” SERVICES POWERED BY HEXAGONAL ARCHITECTURE
DB
SEAT SUGGESTIONS API
@tpierrain (use case driven)
AUDITORIUM
SEATING DOMAIN
INFRA
DB
REPO
(ADAPTER)
SEATS AVAILABILITY
DOMAIN
INFRA
DB
HTTP
HTTP
HTTP
(in proc)
The next step after a monolith modularization is often to split the various hexagons into dedicated services/APIs.
But beware of the Distributed Monolith pitfall occurring very often when the services/APIs aren’t aligned with (sub) domain
concerns (see. Bounded Contexts from DDD).
IProvideUpToDateAuditoriumSeatings
(driven port)

50. OTHER INTENTS #5
• To adapt not only technologies but also external domain models
community

51. AUDITORIUM
LAYOUTS DOMAIN
INFRA
DB
SEAT SUGGESTIONS DOMAIN
INFRASTRUCTURE
HTTP
HEXAGONAL “HACKED” WITH AN ANTI-CORRUPTION LAYER (ACL) ADAPTER
DB
SEAT SUGGESTIONS API
@tpierrain (use case driven)
SEATS AVAILABILITY
DOMAIN
INFRA
DB
HTTP
HTTP
(in proc)
DB
The AuditoriumSeatings ACL (in green) exposes us ready-to-use Auditorium Seatings for shows. It assembles them from various
external sources/APIs. An Auditorium Seating is the Auditorium Layout for a show, with indications about every current seat
availability.
Interesting option/trade-off when we don’t want to couple our real core domain (i.e. to suggest the best possible seats for
groups of people) with how to infer Auditorium Seatings from various external sources and models.
More about it (Hexagonal or not Hexagonal?) : https://tpierrain.blogspot.com/2020/11/hexagonal-or-not-hexagonal.html
Provides Auditorium layout (Topology)
for a show, but with no information
about seats availabilities
Provides list of already
reserved seats for a show
IProvideUpToDateAuditoriumSeatings
(driven port)

52. AUDITORIUM
LAYOUTS DOMAIN
INFRA
DB
SEAT SUGGESTIONS DOMAIN
INFRASTRUCTURE
HTTP
THE SPLIT - “MICRO” SERVICES POWERED BY HEXAGONAL ARCHITECTURE
DB
SEAT SUGGESTIONS API
@tpierrain (use case driven)
AUDITORIUM
SEATING DOMAIN
INFRA
DB
REPO
(ADAPTER)
SEATS AVAILABILITY
DOMAIN
INFRA
DB
HTTP
HTTP
HTTP
(in proc)
The next step after a monolith modularization is often to split the various hexagons into dedicated services/APIs.
But beware of the Distributed Monolith pitfall occurring very often when the services/APIs aren’t aligned with (sub) domain
concerns (see. Bounded Contexts from DDD).
IProvideUpToDateAuditoriumSeatings
(driven port)

53. HEXAGONAL OR NOT HEXAGONAL?
YES?
An Adapter can be an ACL
I may not want my domain to be
polluted by external models or
upstream organizational changes
NO?
I want to stick to Alistair original
motivations (i.e. technological)
 port = only to swap technology

54. HEXAGONAL OR NOT HEXAGONAL?
AND THIS ONE?
Note: an external API is often a
former module extracted from a
modular monolith
Auditorium
Seating API
HTTP
HTTP

55. HEXAGONAL ARCHITECTURE: ONE PATTERN,
MULTIPLE FACETS?
• The technological facet: to easily switch one technology with another
without breaking our core domain code (like plug-ins)
• The testability facet: to easily develop and test an application in isolation
from its eventual run-time devices and databases
• The fast feedback facet: to have good time to market and fast feedbacks
about what is really at stakes for our users
• The tactical DDD facet: to properly split and protect our domain code from the infrastructure one
• The simplicity facet: to reduce layering and complexity of our architectures
• The late architectural decisions facet: to postpone architectural decisions at the right time
• The strategic DDD facet: to adapt not only technologies but also external domain models
• The Refactoring hive facet: to modularize a monolith splitting every Bounded Context into a
hexagon
Community

56. SO…

57. HEXAGONAL OR NOT HEXAGONAL?
YES ?
It’s a multi-facets pattern!
o The technological facet
o The testability facet
o The tactical DDD facet
o The simplicity facet
o The quick feedback facet
o The late architectural
decisions facet
o The strategic DDD facet
http://tpierrain.blogspot.com/2020/11/hexagonal-or-not-hexagonal.html

58. HEXAGONAL OR NOT HEXAGONAL?

59. LOOKS LIKE…
…WE NEED TO FIND NEW
NAMES FOR ALL OUR USAGES
AS A COMMUNITY

60. THANK YOU!
QUESTIONS?