# Ddd Strategic Design

> Use when starting new projects, designing system architecture, identifying bounded contexts, mapping context relationships, system refactoring, system redesign, or when user mentions 'DDD', 'domain-driven design', 'bounded context', 'context mapping', 'microservices design', 'business modeling', 'system boundaries', 'domain thinking', '领域思维', '领域驱动', '重构项目', '重构系统', '重新设计系统', '优化重构系统'.

- **Type:** Skill
- **Install:** `agentstack add skill-konglong87-methodology-skills-ddd-strategic-design`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [konglong87](https://agentstack.voostack.com/s/konglong87)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [konglong87](https://github.com/konglong87)
- **Source:** https://github.com/konglong87/methodology-skills/tree/main/skills/ddd-strategic-design
- **Website:** https://konglong87.github.io/anything-ai/

## Install

```sh
agentstack add skill-konglong87-methodology-skills-ddd-strategic-design
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Domain-Driven Design: Strategic Design

## 前置协议

### 环境检测

```bash
# 检测当前项目信息
PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || echo "unknown")
BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
COMMIT=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown")

echo "PROJECT: $PROJECT_ROOT"
echo "BRANCH: $BRANCH"
echo "COMMIT: $COMMIT"
```

### 前置技能检查

**benefits-from 检查**（推荐但非必须）：

```bash
# 检查 goal-oriented 工件
GOAL_ARTIFACT="memory/artifacts/goal-oriented/latest.json"

if [ -f "$GOAL_ARTIFACT" ]; then
  echo "FOUND: goal-oriented artifact"
  # 提取目标信息，确保设计符合目标
fi

# 检查 first-principles 工件
FP_ARTIFACT="memory/artifacts/first-principles/latest.json"

if [ -f "$FP_ARTIFACT" ]; then
  echo "FOUND: first-principles artifact"
  # 提取第一性原理分析结果，用于指导设计
fi
```

**工件目录初始化**：

```bash
# 确保工件目录存在
mkdir -p memory/artifacts/ddd-strategic
```

### 用户意图确认

根据用户消息判断：

**检查点**：
- [ ] 是否需要设计新系统或重构现有系统
- [ ] 是否涉及多个业务领域或团队
- [ ] 是否需要识别系统边界和上下文关系

**意图分类**：
1. **新系统设计**：从零开始设计系统架构
2. **系统重构**：将单体拆分为微服务
3. **架构优化**：重新梳理上下文边界
4. **业务建模**：梳理业务领域

## Overview

Strategic design focuses on defining bounded contexts and their relationships. A bounded context is a boundary within which a domain model is defined and applicable. Inside the boundary, all terms, rules, and logic have a specific, consistent meaning. Different contexts may use the same terms with different meanings.

**Why it matters:** Without clear boundaries, teams talk past each other. "Customer" means something different to Sales vs Support vs Billing. Strategic design makes these boundaries explicit.

**Core principle:** Language consistency within a boundary, explicit translation between boundaries.

Tactical design happens within each bounded context. See `ddd-tactical-design` skill for implementation details.

## When to Use

**Applicable:**
- Starting a new project or system
- Decomposing a monolith into microservices
- Multiple teams working on the same domain
- Domain logic is complex and domain experts are available
- Language confusion across teams (same term, different meanings)

**Not applicable:**
- Simple CRUD operations with minimal logic
- Single-team small projects ( "Identify Bounded Contexts";
    "Identify Bounded Contexts" -> "Define Context Map";
    "Define Context Map" -> "Architecture Decisions";
    "Architecture Decisions" -> "保存工件";
}
```

### Step 1: Event Storming

Gather domain experts and developers. Use sticky notes to explore the domain:

**Domain Events** (orange): Something that happened
- "Order Placed", "Payment Processed", "Inventory Reserved"
- Write in past tense

**Commands** (blue): What triggers events
- "Place Order", "Process Payment", "Reserve Inventory"
- Write in imperative mood

**Aggregates** (yellow): What handles commands and emits events
- "Order", "Payment", "Inventory"

**External Systems** (pink): Outside dependencies
- "Payment Gateway", "Email Service"

**Actors** (green): Who initiates commands
- "Customer", "Admin", "System"

Process: Start with events, work backward to commands, identify what's needed.

### Step 2: Identify Bounded Contexts

Group related events, commands, and aggregates into contexts:

**Principles:**
- **Semantic consistency**: Same term means same thing within a context
- **Independent evolution**: Each context can change independently
- **Team alignment**: One team owns one context (Conway's Law)

**Questions to ask:**
- Where does language change? (Customer in Sales vs Support)
- Where can we draw a clean boundary?
- What can be deployed independently?
- What team owns this capability?

**Start coarse, refine later.** Too many contexts = integration complexity. Too few = coupling.

### Step 3: Define Context Map

Document relationships between contexts:

| Pattern | Description | When to Use |
|---------|-------------|-------------|
| **Partnership** | Teams succeed or fail together | Tight coordination needed |
| **Customer-Supplier** | Downstream depends on upstream | Upstream serves downstream needs |
| **Conformist** | Downstream conforms to upstream | Upstream cannot be influenced |
| **Anti-Corruption Layer** | Downstream translates upstream model | Protect domain model purity |
| **Open Host Service** | Publish API for multiple consumers | Shared capability |
| **Shared Kernel** | Shared subset of model | Carefully controlled coupling |

**Draw the map:** Which contexts talk to each other? What patterns apply?

### Step 4: Architecture Decisions

Based on context map, decide:

- **Team structure**: One team per context (ideally)
- **Communication**: Synchronous (RPC) vs asynchronous (events)
- **Data ownership**: One context owns data, others subscribe
- **Deployment**: Monolith or microservices? Start monolith-first.

## Thinking Framework

Use this table during Event Storming:

| Question | What to Look For | Example |
|----------|------------------|---------|
| **What events?** | Business-critical things that happened | "OrderPlaced", "PaymentFailed" |
| **What triggers events?** | Commands from users or systems | "PlaceOrder", "RetryPayment" |
| **What boundaries?** | Where language changes | Sales "Customer" ≠ Support "Customer" |
| **Who owns what?** | Team responsibility boundaries | Team A: Orders, Team B: Inventory |
| **How do they communicate?** | Sync vs async, contracts | Events for loose coupling, RPC for tight |

**Bounded Context Checklist:**
- [ ] Language is consistent within the context
- [ ] Can evolve independently (deployable on own schedule)
- [ ] One team can own it (matches Conway's Law)
- [ ] Clear boundaries with other contexts
- [ ] Defined relationships on context map

## Examples

### Case 1: E-commerce System

**Event Storming reveals:**
- Events: OrderPlaced, InventoryReserved, PaymentProcessed, OrderShipped
- Commands: PlaceOrder, ReserveInventory, ProcessPayment, ShipOrder
- Aggregates: Order, Inventory, Payment, Shipment

**Bounded Contexts identified:**

1. **Order Context**
   - Language: Order, OrderItem, Customer (buyer), OrderStatus
   - Team: Order Management Team
   - Events: OrderPlaced, OrderCancelled

2. **Inventory Context**
   - Language: Product, Stock, Warehouse, Reservation
   - Team: Warehouse Team
   - Events: InventoryReserved, StockDepleted

3. **Payment Context**
   - Language: Payment, Transaction, PaymentMethod, Refund
   - Team: Finance Team
   - Events: PaymentProcessed, PaymentFailed

**Context Map:**
- Order → Inventory: Customer-Supplier (Order needs Inventory to reserve)
- Order → Payment: Customer-Supplier (Order needs Payment to process)
- Order publishes OrderPlaced event → Inventory subscribes (async)
- Payment publishes PaymentProcessed event → Order subscribes (async)

**Architecture:** Start as modular monolith. Deploy as microservices if teams scale.

### Case 2: Healthcare System

**Bounded Contexts:**

1. **Patient Management Context**
   - Language: Patient, MedicalRecord, Diagnosis
   - Team: Clinical Team

2. **Appointment Context**
   - Language: Appointment, Schedule, Availability, Slot
   - Team: Scheduling Team

3. **Billing Context**
   - Language: Invoice, Payment, Insurance, Claim
   - Team: Billing Team

**Context Map:**
- Patient Management → Appointment: Shared Kernel (Patient ID)
- Appointment → Billing: Customer-Supplier (Appointments trigger billing)
- Billing has Anti-Corruption Layer for Insurance Provider's external model

## Common Pitfalls

### Pitfall 1: Too Fine-Grained Contexts

**Mistake:** Creating a context for every aggregate or entity.

**Problem:** Excessive integration complexity. Every change touches multiple contexts.

**Solution:** Start with fewer, larger contexts. Split only when you feel coupling pain.

**Rule of thumb:** Can you deploy this independently without coordinating with 3+ other teams? If no, merge contexts.

### Pitfall 2: Ignoring Team Structure

**Mistake:** Designing contexts based on domain purity, ignoring Conway's Law.

**Problem:** One team owns multiple contexts → coupling. Multiple teams own one context → conflict.

**Solution:** Align context boundaries with team boundaries. One team, one context.

### Pitfall 3: Missing Anti-Corruption Layer

**Mistake:** Letting upstream context's model leak into downstream context.

**Problem:** Downstream model becomes polluted with concepts that don't fit its domain.

**Solution:** Add Anti-Corruption Layer. Translate upstream model to downstream model at the boundary.

**Example:** External "User" → ACL translates → Internal "AccountHolder" with different attributes.

## 后置协议

### 工件输出

保存战略设计结果到工件文件：

```bash
# 生成工件文件名
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
ARTIFACT_FILE="memory/artifacts/ddd-strategic/result-$TIMESTAMP.json"

# 写入工件
cat > "$ARTIFACT_FILE" /dev/null | head -1)

if [ -n "$GOAL_FILE" ]; then
  GOAL_STATUS=$(grep "状态：" "$GOAL_FILE" | awk '{print $2}')

  if [ "$GOAL_STATUS" = "pending" ]; then
    echo "Adding milestone: DDD 战略设计完成"

    # 使用 Edit 工具添加里程碑
  fi
fi
```

### 建议后续技能

根据设计结果，推荐后续技能：

**推荐格式**：
```markdown
## 后续建议

基于 DDD 战略设计结果，建议继续执行：

**推荐技能链**：
1. /ddd-tactical-design - 在限界上下文内进行战术设计
2. /mvp-first - 进行 MVP 功能筛选

**根据设计阶段选择**：
- **战术实现** → /ddd-tactical-design（设计聚合、实体、值对象）
- **功能规划** → /mvp-first（筛选 MVP 功能）
- **迭代执行** → /pdca-cycle（进入 PDCA 循环）

是否继续执行？
- A) 执行推荐的技能链
- B) 只执行第一个技能
- C) 不继续，结束当前任务
```

## References

- **Domain-Driven Design** by Eric Evans - The original DDD book
- **Implementing Domain-Driven Design** by Vaughn Vernon - Practical implementation guide
- **Event Storming** by Alberto Brandolini - Collaborative domain exploration
- **Context Mapping** patterns: https://www.infoq.com/articles/ddd-contextmapping/

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [konglong87](https://github.com/konglong87)
- **Source:** [konglong87/methodology-skills](https://github.com/konglong87/methodology-skills)
- **License:** MIT
- **Homepage:** https://konglong87.github.io/anything-ai/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-konglong87-methodology-skills-ddd-strategic-design
- Seller: https://agentstack.voostack.com/s/konglong87
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.