2. Allow an application to equally be driven by users, programs,
automated test, and to be developed and tested in isolation from
its eventual run-time devices and databases.
Intent
3. ● Clean Architecture
● Ports/Adapters
● Left wing side/right side
● Domain-driven design
● Evolutive architecture / VIPER…
Other similar
architectures/buzzwords?
HEXAGONAL ARCHITECTURE
4. How does the kitchen of a chef look like?
Why do we need it?
5. How does the kitchen of a chef look like?
Why do we need it?
Image from Shutterstock here
6. Software is a living creature that needs to
Why do we need a good architecture?
Be maintainable
Evolve
Do several similar and very different things
Be flexible
Be testable Self explanatory
7. ● Put the software at the service of the business.
● Technology is a detail, business is what matters.
● Can your PO read your tests or your code and understands what it does ?
● Push for independence of the business area from the technology infrastructure
● Make it easy to evolve
● Allow re-usability
What is the goal of the Hexagonal
Architecture?
8. How is the Hexagonal Architecture
working?
● Separate the Domain - Business from the rest
14. How is the Hexagonal Architecture
working?
● Users / Application:
○ What is provided to the end user of our domain
○ They need us
● Providers / Infrastructure:
○ What we depend on
15. How is the Hex-Archi working for instance
for us?
16. How is the Hex-Archi working for instance
for us?
At compile time:
18. How is the Hex-Archi working for instance
for us?
At runtime:
public class Program {
public static void Main(String[] args)
{
// 1. Instantiate right-side adapter ("Infrastructure most likely in our case")
// What we depend on
SomeOtherPort infraAdapter = new SomeKindOfAdapter("argument");
// 2. Instantiate the Domain
// Our business logic
ISomePort domain = new LogicThanImplementSomePort(infraAdapter);
// 3. Instantiate the application side
// What our users depend on
SomeRestController controller = new SomeRestController(domain);
}
}
19. Details
● Ports:
○ Interfaces
○ Contract to respect for adapter
● Adapters:
○ Implement interfaces
○ Are interchangeables
○ Are throwable
○ Are mockable
● Example:
○ Replace PostgreSQL by Oracle → no impact on the domain
○ Replace RabbitMQ by Kafka →
20. Details
● Domain:
○ Should use domain language only
○ Should be easy to unit test
○ Could have easily implemented behaviour driven test
○ Could be Domain-driven designed
○ MUST not have any dependency on other parts of the application
○ Lean on Dependency Injection and pass only interfaces
21. Details
● Testing Strategy:
○ Mock / stub / fake your infrastructure adapters
○ Test the whole domain independently of infrastructure or application
○ Can test: Application → Domain
○ Can test: Domain → Infrastructure
○ MUST STILL test infrastructure and application parts
23. BUT ...
● Beware:
○ Your database model isn’t your domain model.
○ You don’t start designing your db to build your domain model
● Challenge yourself:
○ Can your PO/PM write the BDD test for you and read your code and understand it? If yes:
congrats, your architecture should be quite neat and be able to evolve.
○ Embrace changes, to do so you will have to improve your code base and architecture
○ Self discipline
24. TIPS ...
● Multi module projects with right dependencies
● Define your domain language to align everybody
● Ask yourself:
○ Is your code easily testable ?
○ Does it use heavily mocks ? → could be a bad smell
○ Are your decisions reversible? They should be
● The less modules/packages and your code is coupled the better you’ll be
● You want to use different technologies for Application/domain/infra → DO IT, you can, don‘t
base your architecture on the language you use
26. Annexe and content we took ideas from
● https://fr.slideshare.net/nicolascarlo1/hexagonal-architecture-elixir
● https://fr.slideshare.net/ThomasPierrain/coder-sans-peur-du-changement-avec-la-meme-pas-mal-hexagonal-architecture
● https://blog.octo.com/en/hexagonal-architecture-three-principles-and-an-implementation-example/
● https://fr.slideshare.net/nicolascarlo1/the-secrets-of-hexagonal-architecture