Bounded Contexts: Team Topologies and Architecture boundaries aligned
summary
Argues that mapping domain, architecture and team structure together removes friction by splitting a subdomain (flight booking) into concrete bounded contexts — seat selection, payment, upgrades — and treating their interactions as only commands events data. Uses system thinking plus DDD to place contexts on a core-domain chart (value vs complexity), lists nine socio‑technical relationship patterns (customer‑supplier, partnership, shared kernel, open host, anti‑corruption layer), and extends Team Topologies with governing and vendor roles so teams align with upstream/downstream influence. Recommends anti-corruption layer for legacy/vendor integration.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 0:35Problem with misalignment
- 1:40Conways Law
- 7:29Cost and Software Development
- 11:09Stability
- 12:01Domains
- 14:27Bounded Context
- 16:41Payment example
- 18:35Core domain charts
- 27:30Abstract
- 32:33Social and Technical Implications
- 40:22Conclusion
related talks
45mSystems Thinking by combining Team Topologies with Context Maps
55mCharting the uncharted: Discovering and evolving bounded contexts
51mDissecting Bounded Contexts -
43mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
43mAdaptive Socio-Technical Systems with Architecture for Flow
47mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
44mArchitecture for Flow - Wardley Mapping, DDD, and Team Topologies
39mFrom Domain Boundaries to Software Architecture
