apidays Paris 2024 - Hexagonal Modules, Adil Baaj, Theodo

Hexagonal Modules: A Cleaner Approach to Monolithic API Design
Adil Baaj, VP of Engineering at Theodo

apidays Paris 2024 - The Future API Stack for Mass Innovation
December 3 - 5, 2024

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. Hexagonal Modules A Cle an e r Ap p roach to Mon olith ic AP I De sig n Ad il Baaj 0 4 /12/20 24
2. $>whoami The picture can't be displayed. 2 @AdilBaaj /adil -baaj VP of Engineering at Theodo Casablanca 🇲🇲🇲🇲 Morocco Som e te ch n olog ie s I work with
3. How my software engineering jou rn e y b e g an a fe w ye ars ag o…
4. How my software engineering jou rn e y b e g an a fe w ye ars ag o… MODULES DEPENDENCY GRAPH
5. How my software engineering jou rn e y b e g an a fe w ye ars ag o… 🤯🤯 Hard to u n d e rstan d 😭😭 P ain fu l to ad d a fe atu re 💣💣 P ron e to b u g s an d re g re ssion s MODULES DEPENDENCY GRAPH
6. What’s the best software architecture?
7. What’s the best software architecture?
8. What are some traits of a software architecture that allows to m an ag e com p le xity as th e cod e b ase g rows?
9. What are some traits of a software architecture that allows to m an ag e com p le xity as th e cod e b ase g rows? Easy to ad d n e w fu n ction alitie s Easy to te st Easy to trou b le sh oot Easy to d e p loy Re silie n t
10. Monolithic architecture Sim p le st arch ite ctu re to im p le m e n t from scratch Ap p lication is org an ize d an d d e p loye d as a sin g le u n it Obelix delighted with his Monolith
11. Monolithic architecture Sim p le st arch ite ctu re to im p le m e n t from scratch Ap p lication is org an ize d an d d e p loye d as a sin g le u n it Can easily become spaghetti code Obelix unhappy with his Monolith
12. Monolithic architecture Easy to ad d n e w fu n ction alitie s Easy to te st Easy to trou b le sh oot Easy to d e p loy Re silie n t Obelix unhappy with his Monolith
13. Monolithic Layered Architecture Log ical se p aration of te ch n ical laye rs Be tte r se p aration of con ce rn s Can b e im p rove d u sin g He xag on al arch ite ctu re / Cle an cod e ap p roach
14. The problem with layered architecture
15. The problem with layered architecture
16. The problem with layered architecture
18. Monolithic layered architecture Easy to ad d n e w fu n ction alitie s Easy to te st Easy to trou b le sh oot Easy to d e p loy Re silie n t
19. Solution: Isolation of Bounded Contexts
20. Microservices A distributed system is a collection of computer programs that utilize computational resources across multiple, separate computation nodes [ networked computers ] to achieve a common, shared goal . Distributed systems aim to remove bottlenecks or central points of failure from a system. Source: atlassian.com
21. Distributed systems fallacies: ❌ Th e n e twork is re liab le ❌ Late n cy is ze ro ❌ Ban d wid th is in fin ite ❌ Th e n e twork is se cu re ❌ Top olog y d oe sn 't ch an g e ❌ Th e re is on e ad m in istrator ❌ Tran sp ort cost is ze ro ❌ Th e n e twork is h om og e n e ou s ❌ Ve rsion in g is sim p le ❌ Com p e n satin g u p d ate s always work ❌ Ob se rvab ility (software ) is op tion al Microservices *These fallacies were statements made by Peter Deutsch and others at Sun Microsystems, and they explain the false assumptions that people make about distributed systems.
22. *These fallacies statements were made by Peter Deutsch and others at Sun Microsystems, and they explain the false assumptions that people make about distributed systems. Distributed systems fallacies: ❌ Th e n e twork is re liab le ❌ Late n cy is ze ro ❌ Ban d wid th is in fin ite ❌ Th e n e twork is se cu re ❌ Top olog y d oe sn 't ch an g e ❌ Th e re is on e ad m in istrator ❌ Tran sp ort cost is ze ro ❌ Th e n e twork is h om og e n e ou s ❌ Ve rsion in g is sim p le ❌ Com p e n satin g u p d ate s always work ❌ Ob se rvab ility (software ) is op tion al Microservices
23. Microservices Easy to ad d n e w fu n ction alitie s Easy to te st Easy to trou b le sh oot Easy to d e p loy Re silie n t
24. ’[...] you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.’ Martin Fowler - Monolith First Microservices
25. Where I started…
26. Domain contains business logic, unaware of the outside world Use cases to expose the domain Ports as interfaces that abstract the outside world for the domain Adapters that implement ports Step 1: Hexagonal Architecture
27. Domain Use cases P orts Ad ap ters No control points on: Bu sin e ss log ic im p le m e n tation Data laye r arch ite ctu re Ste p 1: He xag on al Arch ite ctu re
28. Each bounded context is isolated b u t th e y can still interact with e ach oth e r Each b ou n d e d con te xt h as its own representation of business concepts / domain model UI + Dom ain (Bou n d e d Con te xt) + In fra = Module Ste p 2: Isolate Bou n d e d Con te xts in Mod u le s
29. Step 2: Isolate Bounded Contexts in Modules BC can n ot talk d ire ctly to e ach oth e r Mod u les e xp ose “in te rn al e n d p oin ts” for oth e r m od u les to con su m e Mod u les con su m e “in te rn al e n d p oin ts” of oth er m od u le s in th eir in frastru ctu re layer
30. Core Domain Logic P orts Ad ap ters Better d ecou p lin g of m od u le s d om ain s No control points on: Data laye r arch ite ctu re Ste p 2: Isolate Bou n d e d Con te xts
31. Step 3: Independent Persistence Sam e DB se rve r, sh are d sch e m a / d b Sam e DB se rve r, d iffe re n t sch e m as / d b s Diffe re n t DB se rve rs, d iffe re n t sch e m as / d b s Diffe re n t p e riste n ce s 🤔🤔
32. Same DB server, shared schema Ste p 3: In d e p e n d e n t P e rsiste n ce
33. Same DB server, different schemas Ste p 3: In d e p e n d e n t P e rsiste n ce
34. Different DB servers, different schemas Ste p 3: In d e p e n d e n t P e rsiste n ce
35. Different peristences 🤔🤔 Ste p 3: In d e p e n d e n t P e rsiste n ce
36. Same DB server, shared schema Sam e DB se rve r, d iffe re n t sch e m as Diffe re n t DB se rve rs, d iffe re n t sch e m as Diffe re n t p e riste n ce s 🤔🤔 Ste p 3: In d e p e n d e n t P e rsiste n ce
37. Same DB server, shared schema Sam e DB se rve r, d iffe re n t sch e m as Diffe re n t DB se rve rs, d iffe re n t sch e m as Diffe re n t p e riste n ce s 🤔🤔 Ste p 3: In d e p e n d e n t P e rsiste n ce
38. Cross modules DB transactions? Cross m od u le tab le fore ig n ke ys? Cross m od u le tab le join ? Same DB server, shared schema Same DB server, different schemas Different DB servers, different schemas Different peristences 🤔🤔 Ste p 3: In d e p e n d e n t P e rsiste n ce
39. Cross modules DB transactions? Cross m od u le tab le fore ig n ke ys? Cross m od u le tab le join ? Same DB server, shared schema Same DB server, different schemas Different DB servers, different schemas Different peristences 🤔🤔 Ste p 3: In d e p e n d e n t P e rsiste n ce
40. Core Domain Logic P orts Ad ap ters Better d ecou p lin g of m od u le s d om ain s Data laye r arch ite ctu re Ste p 3: In d e p e n d e n t P e rsiste n ce
41. Step 4: Event Driven Communication Eve n t d rive n com m u n ication b e twe e n m od u le s Mod u le s con su m in g e ve n t are n ot im p orte d b y oth e r m od u le s - ach ie vin g b e tte r d e cou p lin g
42. Step 4: Event Driven Communication
43. Easy to add new functionalities Easy to te st Easy to trou b le sh oot Easy to d e p loy Re silie n t Ste p 4 : He xag on al Mod u le s
44. Key takeaways • Think of the Modular Monolithic architecture when starting a new project • Start from the hexagonal architecture and move towards the hexagonal modules as you better understand domain boundaries • Think of distributed system fallacies before moving to event driven and / or microservices architecture
45. Questions?