Design Domain-Driven Bounded Contexts
DDD strategic design skill for classifying subdomains, defining bounded contexts, and building a ubiquitous language glossary before implementation.
Why it matters
Define clear domain boundaries and team ownership for complex systems. This skill helps decompose monoliths or service landscapes into manageable, well-defined contexts aligned with business capabilities.
Outcomes
What it gets done
Classify core, supporting, and generic subdomains.
Define bounded contexts around consistency and ownership.
Establish a shared ubiquitous language with domain experts.
Document context boundaries and rationale in ADRs.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-ddd-strategic-design | bash Overview
DDD Strategic Design
A DDD strategic design skill for classifying subdomains, defining bounded contexts, and building a ubiquitous language glossary. Use for classifying subdomains, splitting domain boundaries, or aligning team ownership; not for stable already-bounded models or tactical/infrastructure work alone.
What it does
This skill applies Domain-Driven Design strategic design to define core, supporting, and generic subdomains, split a monolith or service landscape by domain boundaries, align teams and ownership with bounded contexts, and build a shared ubiquitous language with domain experts.
Its instructions: extract domain capabilities and classify subdomains; define bounded contexts around consistency and ownership; establish a ubiquitous language glossary along with anti-terms to avoid; and capture context boundaries in ADRs before implementation. It references references/strategic-design-template.md for detailed templates when needed.
Its required artifacts: a subdomain classification table, a bounded context catalog, a glossary with canonical terms, and boundary decisions with documented rationale.
Use @ddd-strategic-design to map our commerce domain into bounded contexts,
classify subdomains, and propose team ownership.
When to use - and when NOT to
Use this skill when defining core/supporting/generic subdomains, splitting a monolith or service landscape by domain boundaries, aligning teams and ownership with bounded contexts, or building a shared ubiquitous language with domain experts.
Not when the domain model is stable and already well bounded, when only tactical code patterns are needed, or for purely infrastructure or UI-oriented tasks. This skill does not produce executable code, cannot infer business truth without stakeholder input, and should be followed by tactical design before implementation.
Inputs and outputs
Inputs: a business domain or existing monolith/service landscape needing subdomain classification and bounded-context definition, with access to domain experts.
Outputs: a subdomain classification table, a bounded context catalog, a ubiquitous language glossary with canonical terms, and documented boundary decisions with rationale (captured as ADRs).
Integrations
References references/strategic-design-template.md for detailed strategic design templates.
Who it's for
Architects and teams performing DDD strategic design to classify subdomains, define bounded contexts, and align team ownership before tactical implementation.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.