Hexagonal Modules : A Cleaner Approach to Monolithic API Design
summary
Combines hexagonal modules (ports and adapters per bounded context) with a modular monolith claim: cleaner, testable Node.js APIs backed by MySQL and React clients. Modules contain UI, domain and infrastructure layers; prefer schema per module on the same DB server, forbid cross‑module transactions and joins, allow lightweight foreign keys for consistency. Add an event broker to absorb bursts and decouple services. Architecture eases later extraction of a module into a microservice.
AI-written summary · about
chapters (12)
- 0:00Hexagonal Modules intro
- 2:30Maintainable architecture traits
- 3:54Monolith limitations
- 4:37Layered monolith challenges
- 5:41Bounded contexts tradeoffs
- 9:15Why start monolithic
- 9:37Hexagonal core principles
- 11:05Isolating bounded contexts
- 12:55Decoupling data layers
- 15:07Event-driven resilience
- 16:55Best-of-both solution
- 17:39Key takeaways
related talks
52mWhy not all hexagons have eight sides
25mHexagonal Architecture in Monoliths and Microservices
45mHooked on the Hexagon, Node JS Didn't Really Help Me Stay Clean
01h 51mHexagonal Architecturoplasty of a Backend: Open‑Code Operation
15mHexagonal Architecture: How to Beat Spaghetti Code?
51mHexagonal Architecture to the rescue
57mHow to Build a Hexagon: Pragmatic Architecture for Client Applications
47mHexagonal Architecture in Practice, Live Coding That Will Make Your Applications More Sustainable