Stats
Actions
Tags
From s2s
Guides domain modeling using DDD strategic patterns: bounded contexts, context maps, subdomain analysis, and ubiquitous language. Useful for decomposing monoliths or designing microservices.
How this skill is triggered — by the user, by Claude, or both
Slash command
/s2s:ddd-strategicThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Domain-Driven Design (DDD) strategic patterns help teams understand complex business domains and define clear boundaries between system components. This skill focuses on strategic patterns used during requirements and architecture discussions, not implementation-level tactical patterns.
Domain-Driven Design (DDD) strategic patterns help teams understand complex business domains and define clear boundaries between system components. This skill focuses on strategic patterns used during requirements and architecture discussions, not implementation-level tactical patterns.
Not all parts of a domain are equally important:
| Type | Importance | Investment | Example |
|---|---|---|---|
| Core | Competitive advantage | High - build custom | Recommendation engine, Pricing algorithm |
| Supporting | Necessary but not differentiating | Medium - build or buy | Reporting, Notifications |
| Generic | Common across industries | Low - buy or use SaaS | Authentication, Payments, Email |
A Bounded Context is a semantic boundary where terms have specific meanings.
| Property | Description |
|---|---|
| Linguistic | Same term can mean different things in different contexts |
| Team | Often aligned with team ownership |
| Deployment | Can be deployed independently |
| Data | Owns its data, doesn't share database |
| Context | Customer Means | Key Attributes |
|---|---|---|
| Sales | Lead/Prospect | Contact info, Pipeline stage, Deal size |
| Billing | Account | Payment method, Invoices, Credit limit |
| Support | User | Tickets, SLA, Satisfaction score |
| Shipping | Recipient | Address, Delivery preferences |
Insight: Each context has its own Customer model. Don't force a "universal customer" entity.
Context maps show how bounded contexts relate to each other.
| Pattern | Direction | Description | Use When |
|---|---|---|---|
| Partnership | ⟷ | Teams coordinate closely | Mutual dependency, aligned goals |
| Shared Kernel | ⟷ | Shared code/model subset | Limited overlap, high trust |
| Customer-Supplier | ← | Downstream depends on upstream | Clear dependency direction |
| Conformist | ← | Downstream adopts upstream model | No influence over upstream |
| Anticorruption Layer (ACL) | ← | Translation layer protects downstream | Upstream model doesn't fit |
| Open Host Service | → | Upstream exposes public API | Multiple consumers |
| Published Language | → | Documented interchange format | External consumers |
| Separate Ways | ✗ | No integration | Costs outweigh benefits |
┌─────────────────┐ Partnership ┌─────────────────┐
│ Sales │◄──────────────────►│ Marketing │
└────────┬────────┘ └─────────────────┘
│
│ Customer-Supplier
▼
┌─────────────────┐ ACL ┌─────────────────┐
│ Billing │◄───────────────────│ Legacy ERP │
└────────┬────────┘ └─────────────────┘
│
│ Open Host Service
▼
┌─────────────────┐
│ Reporting │ (Conformist)
└─────────────────┘
A shared vocabulary that is:
| Activity | Output |
|---|---|
| Domain expert interviews | Term definitions, Business rules |
| Event Storming | Events, Commands, Aggregates |
| Example mapping | Concrete scenarios, Edge cases |
| Glossary creation | Canonical definitions |
When the same word means different things to different people:
A collaborative workshop technique for domain exploration.
| Color | Element | Description | Question |
|---|---|---|---|
| 🟧 Orange | Domain Event | Something that happened | "What happened?" |
| 🟦 Blue | Command | Trigger for an event | "What caused this?" |
| 🟨 Yellow | Actor | Who issues the command | "Who did this?" |
| 🟪 Purple | Policy | Reactive logic | "When this happens, then..." |
| 🟩 Green | Read Model | Information needed | "What info was needed?" |
| 🟥 Pink | External System | Outside integration | "Who else is involved?" |
| 🔴 Red | Hot Spot | Problem/Question | "Something's unclear here" |
| 🟫 Tan | Aggregate | Consistency boundary | "What data changes together?" |
[Actor] ──triggers──> [Command] ──causes──> [Domain Event]
│
▼
[Policy] ──may trigger──> [Command]
"Organizations produce designs that mirror their communication structures."
Implication: Bounded context boundaries should consider team structure.
| Signal | Possible Issue |
|---|---|
| Same term, different meanings | Missing context boundary |
| Long coordination cycles | Too many cross-context dependencies |
| Large shared database | Contexts not properly separated |
| Frequent breaking changes | Insufficient ACL protection |
| "We need to sync with Team X first" | Partnership or Customer-Supplier needed |
| Workflow | Artifact | Purpose |
|---|---|---|
| specs | Subdomain classification | Investment decisions |
| specs | Glossary / Ubiquitous Language | Shared vocabulary |
| specs | Domain Events list | Business capability mapping |
| design | Context Map | Integration architecture |
| design | Context boundaries | Service/module design |
| Anti-Pattern | Problem | Better Approach |
|---|---|---|
| Universal Entity | "Customer" used everywhere same way | Separate models per context |
| Shared Database | All services read/write same tables | Each context owns its data |
| Big Ball of Mud | No clear boundaries | Identify contexts, draw lines |
| Anemic Domain Model | Logic in services, dumb data objects | (Tactical - but flag if seen) |
| Distributed Monolith | Microservices but tightly coupled | Proper context boundaries first |
| Level | Focus | Roundtable Relevance |
|---|---|---|
| Strategic | Contexts, Maps, Subdomains | ✅ High - discuss in specs/design |
| Tactical | Entities, Aggregates, Repositories | ⚠️ Low - implementation detail |
This skill focuses on strategic patterns for roundtable discussions.
npx claudepluginhub spec2ship/spec2ship --plugin s2sDesigns DDD strategic artifacts: subdomain classification, bounded contexts, and ubiquitous language for complex business domains.
Designs DDD strategic artifacts including subdomains, bounded contexts, and ubiquitous language for complex business domains. Useful for classifying subdomains, splitting monoliths, and aligning teams.