Domain-centric? Why Hexagonal- and Onion-Architecture are answers to the wrong question
summary
Argues that hexagonal/onion focus misses the real question: design for cohesion and vertical slices rather than technical layers, so changes stay inside modules. Demonstrates tooling: Spring Modulith plus an IDE feature that reads Jmolecules stereotypes to surface ports/adapters in VS Code/Eclipse (IntelliJ coming). Recounts a case where 500 OSGi bundles are consolidated to 500 OSGi bundles → 3 apps, reducing accidental complexity. Claim: keep internals package-private, expose only deliberate module boundaries — it works in practice.
AI-written summary · about
chapters (8)
- 0:00The cost of change
- 2:20Coupling and cohesion
- 8:36Analyzing architectural styles
- 15:30Critique of domain-centricity
- 21:20Functional decomposition
- 30:21Practical design strategies
- 35:06Tools and IDE integration
- 43:43Q&A and closing thoughts
related talks
45mWhy Hexagonal and Onion Architecture Are Answers to The Wrong Question
52mWhy not all hexagons have eight sides
49mMid-sized building blocks and hexagonal architecture
46mHexagonal at Scale, with DDD and microservices!
01h 01mWhy not all hexagons have eight sides
47mThe End of Layered Architectures with the Hexagonal Approach
45mThe End of Layered Architectures with the Hexagonal Approach
48mLet's adopt the `clean archigonal`