Using Boundary-Driven Development to beat code complexity
summary
Claim: carefully designed internal boundaries stop a monolith turning into a Big Ball of Mud by making dependencies intentional and optimizable. Concrete tools and patterns: dependency inversion principle applied at architecture level, onion/hexagonal/clean architectures, vertical-slice modules, package separation for test helpers, and explicit internal visibility. Surprising numbers and practices: duplicate code across boundaries instead of dogmatic DRY, test each boundary as a unit, use composition layer to wire things. Examples and artifacts: IStoreOrder interface, liquid projections library, distributed-lock provider, Rider/JetBrains IDE analysis and Copilot for code understanding.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:25Code coupling problem
- 4:55Traditional solutions fail
- 5:15Internal boundaries in code
- 7:03Dependency inversion principle
- 11:21Dependency inversion in architecture
- 14:32Code by functionality over layers
- 16:16Microservices to modular monoliths
- 17:24Duplicating code reduces coupling
- 19:33Testing within boundaries
- 21:18Reducing package-level coupling
- 23:45Libraries without hidden magic
- 27:37Code visibility and refactoring
- 30:30Enforcing boundaries with contracts
- 32:57Tell don't ask in practice
- 36:15Domain logic in value objects
- 38:04Tools for understanding code
- 39:10Refactoring legacy systems
- 40:14Q&A
related talks
44mDependencies; Devil or Darling?
33mBuilding resilient frontend architecture
37mBuilt to last: A domain-driven approach to beautiful systems
01h 29mArchitecture Beyond Clean & Hexagonal
58mGetting a grip on your code dependencies
46mBoundaries
40mBuilding resilient frontend architecture
52mEvolving a Pragmatic, Clean Architecture A Craftsman's Guide