Dependencies; Devil or Darling?
summary
Argument that teams waste huge time administrating dependencies without fixing them and that the fix is organizational and design choices not meetings. Uses Domain-Driven Design patterns (bounded contexts, anti-corruption layer, shared kernel), XP practices like test‑driven development, and Team Topologies / Conway’s Law. Shows a pathological design of 40,000 microservices and large-team handoff counts that move complexity into the seams. Demonstrates that forking or ACL translation can free teams and that TDD actually guides safer decoupling.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 0:43Why dependencies matter
- 3:10Problems with dependencies
- 7:43Local vs global throughput
- 13:03Taylorism inefficiency
- 15:32Domain-driven design overview
- 17:22Coupling vs cohesion trade-offs
- 19:51Enterprise model pitfalls
- 22:24XP solutions and team design
- 26:20Conway’s law and team topologies
- 28:53DDD as dependency management
- 31:18Buy vs build core subdomains
- 33:05Bounded contexts isolation
- 34:30Conformist and anti-corruption layers
- 36:17Ubiquitous language collaboration
- 38:47Escaping shared kernel
- 39:29Platform and third-party risks
- 40:57Dependencies summary
- 41:41Q&A third-party stability
related talks
41mUsing Boundary-Driven Development to beat code complexity
58mDDD really matters!
40mBuilding resilient frontend architecture
42mConquering Your Dependencies, the Long Road to Organizational Agility
33mFrom Enterprise Architecture to Software Design - Critical Thinking
58mGetting a grip on your code dependencies
45mLearning to Love DDD - a Tale of Two Products
55mHigh-speed DDD