7. HEXAGONAL ARCHITECTURE GOAL(S)
Sub goals
1. De
fi
ne a Domain Speci
fi
c Language (DSL)
2. Switch easily between technologies
without changing domain code
7
9. HEXAGONAL ARCHITECTURE COMPONENTS
➤ A hexagon representing the domain
Create your DSL with all the people involved on the project if
possible (BIZ, DEV and QA)
Domain code
9
12. HEXAGONAL ARCHITECTURE COMPONENTS
➤ A hexagon representing the domain
➤ The ports provided by the hexagon
A port represent the intention of the dialog
Don’t think of it as (only) a technical part (as a Java interface
for instance)
« This is for …ing"
Domain code
: port
12
14. HEXAGONAL ARCHITECTURE COMPONENTS
➤ A hexagon representing the domain
➤ The ports provided by the hexagon
➤ The adapters containing the technical code
The domain is sel
fi
sh. It speaks only its own
language with the infrastructure
14
17. HEXAGONAL ARCHITECTURE OTHERS ELEMENTS
➤ To the left of the hexagon, we have the primary actors, the one
who trigger the system, composed of drivers (cause the
application to take action)
➤ To the right of the hexagon, we have the secondary actor, the
one triggered, composed of recipients (get noti
fi
ed by the
application) and repositories (provide data to the application)
17
19. THE BENEFITS
Separation of concerns
The domain code is « completely » independent of the
infrastructure code:
➤ avoid to mix domain and technical code
➤ Ease the technology watch
19
21. THE BENEFITS
➤ Separation of concerns
➤ Domain centric language via the DSL => DDD
➤ Testing (
fi
rst) easily with or without having the
physical infrastructure
21
22. THE BENEFITS
➤ Separation of concerns
➤ Domain centric language via the DSL => DDD
➤ Testing easily without having the physical infrastructure
➤ Easy to implements another adapter for a new
technology
=> change technology easily without changing domain code :
oracle adapter to mongodb adapter
22
23. HEXAGONAL ARCHITECTURE REPRESENTATION
Domain code
Oracle
DB
Mongo
DB
Adapter
(Technical code)
Adapter
(Technical code)
23
Multiple adapters for one port without changing domain code : port
25. HOW DO WE DO IT ?
Dependency Inversion
- High-level modules should not depend on low-level modules. Both should
depend on abstractions.
- Abstractions should not depend on details. Details should depend on
abstractions.
25
26. HOW DO WE DO IT ?
26
Dependency Inversion: The intention defined by the high level component (Domain)
27. HOW DO WE DO IT ?
27
Dependency Inversion: The low level component (Infrastructure) respecting the previous intention
28. HOW DO WE DO IT ?
Dependency Injection
(Con
fi
gurable dependency)
In software engineering, dependency injection is a technique whereby one
object supplies the dependencies of another object.
A dependency is an object that can be used (a service).
An injection is the passing of a dependency to a dependent object (a client) that
would use it.
28
29. HOW DO WE DO IT ?
29
Dependency Injection: Constructor injection in the present example in the Domain
30. HOW DO WE DO IT ?
30
Dependency Injection: Constructor injection in the present example in the Driver Infrastructure
31. HOW DO WE DO IT ?
It’s just common sense
Just di
ff
erentiate what’s part of the domain and what’s part of
the infrastructure
Beware to not create object mixing domain and technical part
31
35. CONCLUSION
➤ Separate the domain and the infrastructure parts
➤ Involve, if possible, all the team member to
de
fi
ne your Domain language
35
36. CONCLUSION
➤ Separate the domain and the infrastructure parts
➤ Involve, if possible, all the team member to de
fi
ne your
Domain language
➤ The domain is sel
fi
sh. It speaks only with its
language with the infrastructure
36
37. CONCLUSION
➤ Separate the domain and the infrastructure parts
➤ Involve, if possible, all the team member to de
fi
ne your
Domain language
➤ The domain is sel
fi
sh. It speaks only with its language with
the infrastructure
➤ Do not create objects mixing domain and
infrastructure parts
37
38. CONCLUSION
➤ Separate the domain and the infrastructure parts
➤ Involve, if possible, all the team member to de
fi
ne your
Domain language
➤ The domain is sel
fi
sh. It speaks only with its language with
the infrastructure
➤ Do not create objects between domain and infrastructure
parts
➤ It’s a real thing ^^
38
39. It’s a very simple architecture
Just do it ;-)
39