Why not all hexagons have eight sides
summary
Argues hexagonal architecture concretely solves layered architecture’s control-flow and coupling problems by pushing infrastructure above domain and using ports and adapters to invert dependencies; shows Spring Data JPA as a common secondary adapter pattern with a mapping layer between persistence and domain models, and recommends modular-monolith boundaries with SPIs so one implementation change collocates impact. Recommends three testing levels (API tests with testcontainers and WireMock, module-level fakes, and focused aggregate tests). Notes practical limits: transactions, lazy-loading and mapping cost, and adapter interchangeability is useful but not magic.
AI-written summary · about
chapters (11)
- 0:00Introduction and warmup
- 2:58Limitations of hexagonal architecture
- 15:38Database-centric architecture problems
- 25:13Horizontal vs vertical layer splitting
- 33:02Modular monoliths and context boundaries
- 37:16Adapters and dependency inversion
- 48:41Hexagonal architecture limits and transactions
- 50:50What is architecture really
- 52:13Q&A on lazy loading and domain models
- 55:03Q&A on annotations and model separation
- 57:49Q&A on testing in hexagonal architecture
related talks
52mWhy not all hexagons have eight sides
15mHexagonal Architecture: How to Beat Spaghetti Code?
25mHexagonal Architecture in Monoliths and Microservices
50mHexagonal Architecture in Practice, Live Coding That Will Make Your Applications More Sustainable
47mThe End of Layered Architectures with the Hexagonal Approach
46mHexagonal Architecture in Practice
45mThe End of Layered Architectures with the Hexagonal Approach
47mHexagonal Architecture in Practice, Live Coding That Will Make Your Applications More Sustainable