Talk was given at OnlinePajak to explain what is the Hexagonal architecture as well as a few tips of how we did it in our team.

1. Hexagonal Architecture
Nicolas Guignard

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

9. How is the Hexagonal Architecture
working?

10. How is the Hexagonal Architecture
working?
● Technical layers have dependencies with the domain, outside-in

11. How is the Hexagonal Architecture
working?
This looks like some Circle Architecture no ?
Not reallyyyyyyyy

12. How is the Hexagonal Architecture
working?

13. How is the Hexagonal Architecture
working?

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:

17. At compile time:
Class diagram

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

22. A good architect defers decisions
Quote?

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

25. Does it scale?
Yes but what if ?

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

27. Thank You
www.online-pajak.com
QUESTIONS ?