Good Fences Make Good Neighbours
summary
Claim: modularity fails because teams and code are treated as purely technical; treating design as a social-technical systems problem raises success odds. Uses event storming, business capability mapping and context-mapping to find seams, then maps domains to teams and APIs. Examples: naive microservice splits (billing carved out) produce a distributed monolith; DORA-style data claim that loosely coupled, encapsulated architecture drives delivery performance more than CI/CD. Outcome: synthesis-before-analysis reduces rewrites and coordination waste.
AI-written summary · about
chapters (22)
- 0:00Introduction and confession
- 1:11System thinking shift
- 2:58Fences as boundaries
- 5:29Boundary purpose and flaws
- 7:13Why modularity matters
- 8:18Cognitive load and boundaries
- 11:06Scaling organizations
- 13:17Architecture and agility
- 16:27Complexity and non-linearity
- 17:52Systems as parts and wholes
- 20:24Reductionism vs synthesis
- 23:14Purposeful systems
- 27:06Open systems and teams
- 28:12Finding module seams
- 32:05Top-down synthesis approach
- 33:29Business capability mapping
- 34:53Event storming technique
- 35:55Context mapping in teams
- 37:43Self-managing teams
- 39:27Emergence pitfalls
- 40:10Multiple perspectives
- 41:37Wrap-up and system age
related talks
52mGood Fences Make Good Neighbours
59mGood Fences Make Good Neighbors
48mGood Fences Make Good Neighbours
46mGood Fences Make Good Neighbours
48mModularization — It Was Supposed to Be Beautiful but Turned Out as Usual :(
31mModularity in open systems
49mRealizing Domain Design Through Architectural Modularity ...
43mAdaptive Socio-Technical Systems with Architecture for Flow