bounded-context-mappinglisted

Use when drawing Domain-Driven Design boundaries: bounded contexts, context maps, ownership seams, upstream/downstream relationships, anti-corruption layers, shared kernels, and translation boundaries. Do NOT use for pre-DDD entity discovery (use `conceptual-modeling`), database schema design (use `data-modeling`), or HTTP endpoint design (use `api-design`). Do NOT use for list entities, attributes, and cardinalities before any architecture decision. Do NOT use for create SQL tables, foreign keys, and indexes. Do NOT use for design REST routes and response envelopes. Do NOT use for write an ADR for the boundary decision after we already chose it. Do NOT use for persistence structure after context boundaries inform ownership (use data-modeling). Do NOT use for external endpoint shape (use api-design).
jacob-balslev/skill-graph · ★ 0 · API & Backend · score 68

Install: claude install-skill jacob-balslev/skill-graph

# Bounded Context Mapping ## Coverage Map domain ownership boundaries and relationships between contexts. Covers bounded context naming, context maps, ubiquitous language separation, upstream/downstream relationships, shared kernel, conformist, customer/supplier, partnership, open host service, published language, anti-corruption layer, and boundary validation against real change scenarios. ## Philosophy A bounded context is a language and ownership boundary, not a deployment unit. Splitting services without splitting language creates distributed coupling. Keeping one module while mixing incompatible meanings creates hidden domain bugs. The central question is: "Where does this word mean something different?" Those differences drive boundaries more reliably than folder layout, teams, or database tables. ## Method 1. Extract candidate terms and workflows from requirements, code, docs, and incidents. 2. Mark terms whose meaning changes by actor or workflow. 3. Group concepts that change together under the same business capability. 4. Draw context boundaries around language consistency, not technical layers. 5. Label relationships: upstream/downstream, partnership, shared kernel, conformist, or anti-corruption. 6. Define translation points and ownership of canonical terms. 7. Stress-test with change scenarios: who changes, who breaks, who must approve? ## Verification - [ ] Each context has a coherent language that does not overload key terms - [ ] Cross-context communi