Good Fences Make Good Neighbours
summary
Argues that modularity only succeeds when boundaries are chosen with a sociotechnical view, combining top‑down synthesis and bottom‑up emergence; recommends business capability mapping and event storming plus DDD and Team Topologies as concrete tools, expects continuous refactoring rather than one‑time splits, and warns a one‑team‑per‑module rule reveals wrong slices (bottlenecks → platform or different slice). Traces lineage back to 1972 information hiding, and shows measurable gains in lead time and autonomy when architecture and org structure align.
AI-written summary · about
chapters (27)
- 0:00Introduction
- 1:06Why boundaries matter
- 3:34Designed boundaries
- 5:18Cognitive load and modularity
- 7:45Autonomous teams
- 9:32Speed and modularity
- 11:19Myth of big ball of mud
- 12:00Loose coupling and cohesion
- 14:05Agility versus technical debt
- 15:50Local optimization risks
- 16:52What is a system
- 18:18Purposeful systems
- 20:24Machine age to systems thinking
- 21:48Systems beyond parts
- 23:54Natural seams in systems
- 26:19Information hiding and design
- 28:05Top-down vs bottom-up modularization
- 29:29Business capabilities alignment
- 31:13DDD and bounded contexts
- 32:17Emergent design limits
- 34:02Analysis versus synthesis
- 35:46Conclusion and key takeaways
- 36:06Q&A: Architecture pitfalls
- 37:07Q&A: Personal skills
- 39:36Q&A: Team scalability
- 42:44Q&A: Event storming
- 45:11Q&A: Risk-averse orgs
related talks
52mGood Fences Make Good Neighbours
43mGood Fences Make Good Neighbours
46mGood Fences Make Good Neighbours
31mModularity in open systems
01mMark Richards at DDD Europe
43mAdaptive Socio-Technical Systems with Architecture for Flow
47mBounded Contexts: Team Topologies and Architecture boundaries aligned
48mModularization — It Was Supposed to Be Beautiful but Turned Out as Usual :(