ddd-contexts

DDD Contexts

English version: English

When to Use

• Subdomains have been classified, and the bounded context boundaries of the solution space need to be designed.
• A Ubiquitous Language needs to be established for each context to eliminate terminology ambiguity.
• ddd-aggregates When the report states "invariants span multiple contexts", or ddd-model-review when the report states "term conflict rate > 20%", re-execute as a backtracking target.

Input Requirements

• Required: Subdomain classification table and core domain declaration (from ddd-subdomains), event stream and hotspot annotations (from ddd-discover）。
• Optional: Organizational information (team boundaries, delivery cadence), terminology seeds (from ddd-scope）。

Process

1. Clustering: Based on consistency boundaries and language boundaries, cluster capabilities into context candidates. Terms within a context must have a unique meaning.
2. Define Responsibilities: For each context, clarify business responsibilities, core concepts, main events, and data ownership.
3. Establish Language: Establish a definition for each core term within the context (including 1 business example), and annotate synonyms and anti-terms.
4. Draw Boundaries: Clarify which concepts are valid only within this context and which concepts must be translated when crossing contexts.
5. Ownership and ADR: Specify the responsible team, decision-makers, and contract Owner; output ADRs for boundary decisions (including rationale, trade-offs, risks, and alternatives).
6. Conflict Handling: Handle terms with the same name but different meanings across contexts—provide translation strategies or renaming suggestions.

Output

Artifact	Structural Requirements
Context Catalog	Table: context name, responsibilities, core terms, main events, data ownership, responsible team
Ubiquitous Language Glossary	Table: term, definition, business example, owning context, synonyms, anti-terms, conflict handling
Anti-term List	Table: forbidden word, reason for prohibition, recommended replacement
Boundary ADR List	Each entry includes: decision, rationale, trade-offs, risks, alternatives
Language Evolution Rules	List: addition/change process, review roles, versioning strategy

Validation Checklist

• Each context has clear "responsibilities" and "non-responsibilities"
• Data ownership has no conflicts; cross-context access must go through contracts/translation
• Each context has at least 1 explicit trade-off point and risk point (ADR)
• All term conflicts have been handled (translation or renaming)
• The anti-term list covers technical word pollution (generalized words such as Manager, Processor, Handler, etc.) and vague business words
• If intermediate concepts of the "request/intent" type (such as ShippingRequest, OrderDraft, BookingIntent) are introduced in the ordering/transaction process, their lifecycle relationship with the main aggregate has been declared (promoted to an independent aggregate vs. equivalent to a VO of the main aggregate); both choices are legal but must be explicitly stated and recorded in an ADR

Backtracking Triggers

• 5 terms have irreconcilable cross-context conflicts → backtrack to ddd-discover, insufficient domain understanding.

• By ddd-aggregates Trigger: invariants span multiple contexts → consistency requirements are split by boundaries and need to be redrawn.
• Triggered by ddd-model-review : aggregate boundaries conflict with context boundaries, or terminology conflict rate > 20%.

Example

@ddd-contexts
基于以下子域分类和事件流，帮我设计限界上下文：
- Core: 预订与冲突管理
- Supporting: 会议室资源管理
- Generic: 用户身份与权限
[粘贴事件流表]
请输出上下文目录、通用语言词汇表、边界 ADR。