domain-model-boundaries-mapper

领域模型与边界映射器

使用领域驱动设计映射领域边界和所有权。

领域映射模板

# Domain Map: E-Commerce Platform

## Bounded Contexts

### 1. Customer Management

**Core Domain:** User accounts, profiles, preferences
**Owner:** Customer Team
**Ubiquitous Language:**

- Customer: Registered user with account
- Profile: Customer personal information
- Preferences: User settings and choices

**Entities:**

- Customer (id, email, name)
- Address (id, customer_id, street, city)
- PaymentMethod (id, customer_id, type, token)

**Bounded Context Diagram:**

┌─────────────────────────────┐ │ 客户管理 │ │ ┌─────────┐ ┌──────────┐ │ │ │客户 │ │ 地址 │ │ │ └─────────┘ └──────────┘ │ │ ┌─────────────────────┐ │ │ │ 支付方式 │ │ │ └─────────────────────┘ │ └─────────────────────────────┘

### 2. Order Management
**Core Domain:** Order processing, fulfillment
**Owner:** Orders Team
**Ubiquitous Language:**
- Order: Purchase request with line items
- LineItem: Product quantity in order
- Fulfillment: Physical delivery of order

**Entities:**
- Order (id, customer_id, status, total)
- LineItem (id, order_id, product_id, quantity)
- Shipment (id, order_id, tracking_number)

### 3. Product Catalog
**Core Domain:** Product information, inventory
**Owner:** Catalog Team
**Ubiquitous Language:**
- Product: Sellable item
- SKU: Stock keeping unit
- Inventory: Available stock

**Entities:**
- Product (id, name, price, description)
- Inventory (sku, quantity, warehouse_id)

## Context Relationships

客户管理 ──────▶ 订单管理 （customer_id）

产品目录 ──────▶ 订单管理 （product_id）

订单管理 ──────▶ 履约 （订单事件）

## Anti-Corruption Layers

### Order Management → Customer Management
**Problem:** Orders need customer data but shouldn't depend on Customer domain model

**Solution:** Customer Adapter
```typescript
// Order domain's view of customer
interface CustomerForOrder {
  id: string;
  shippingAddress: Address;
  billingAddress: Address;
}

// Adapter translates Customer domain to Order domain
class CustomerAdapter {
  async getCustomerForOrder(customerId: string): Promise<CustomerForOrder> {
    const customer = await customerService.getCustomer(customerId);
    return {
      id: customer.id,
      shippingAddress: this.toOrderAddress(customer.defaultShippingAddress),
      billingAddress: this.toOrderAddress(customer.defaultBillingAddress),
    };
  }
}

依赖关系图

┌──────────────┐
│   Customer   │
└──────┬───────┘
       │
       ▼
┌──────────────┐      ┌────────────┐
│    Orders    │─────▶│  Products  │
└──────┬───────┘      └────────────┘
       │
       ▼
┌──────────────┐
│ Fulfillment  │
└──────────────┘

依赖规则：

• 客户没有依赖项
• 订单依赖客户（读取）和产品（读取）
• 履约依赖订单（事件）

接口契约

客户管理 → 订单

// Public interface exposed by Customer domain
interface CustomerService {
  getCustomer(id: string): Promise<Customer>;
  getCustomerAddresses(id: string): Promise<Address[]>;
}

// Events published
interface CustomerUpdated {
  customerId: string;
  email: string;
  name: string;
}

产品目录 → 订单

interface ProductService {
  getProduct(id: string): Promise<Product>;
  checkAvailability(sku: string, quantity: number): Promise<boolean>;
  reserveInventory(items: ReservationRequest[]): Promise<Reservation>;
}

重构建议

问题 1：紧密耦合

现状： 订单直接查询客户数据库 问题： 破坏限界上下文，造成耦合 建议： 改用客户 API

// ❌ Before: Direct database access
const customer = await db.customers.findById(customerId);

// ✅ After: API call through adapter
const customer = await customerAdapter.getCustomerForOrder(customerId);

问题 2：共享模型

现状： 不同上下文共用同一个 User 模型 问题： 一个上下文中的更改会影响其他上下文 建议： 为每个上下文使用独立模型

// Customer context
interface Customer {
  id: string;
  email: string;
  profile: CustomerProfile;
  preferences: CustomerPreferences;
}

// Order context (different model!)
interface OrderCustomer {
  id: string;
  shippingAddress: Address;
  billingAddress: Address;
}

问题 3：上帝服务

现状： OrderService 负责订单、库存、支付和配送 问题： 单个服务负责的内容过多 建议： 提取限界上下文

• OrderService：订单生命周期
• InventoryService：库存管理
• PaymentService：支付处理
• FulfillmentService：配送

战略设计模式

模式 1：共享内核

适用场景： 两个上下文必须共享部分代码 示例： 通用值对象（Money、Address）

// Shared kernel (minimal!)
class Money {
  constructor(public amount: number, public currency: string) {}
}

模式 2：客户/供应商

适用场景： 一个上下文依赖另一个上下文 示例： 订单（客户）依赖产品（供应商）

• 供应商定义接口
• 客户根据自身需求进行适配

模式 3：发布语言

适用场景： 多个上下文需要相同的数据 示例： 产品事件

interface ProductCreated {
  productId: string;
  name: string;
  price: Money;
  publishedAt: Date;
}

迁移策略

阶段 1：确定边界

• 将现有代码映射到各个领域
• 确定耦合点
• 记录依赖关系

阶段 2：定义接口

• 设计上下文之间的 API
• 创建适配器层
• 定义事件契约

阶段 3：解耦

• 用 API 替换直接数据库访问
• 引入防腐层
• 为每个上下文分离模型

阶段 4：提取服务（可选）

• 将上下文迁移到独立服务
• 实现 API 网关
• 搭建事件总线

最佳实践

1. 通用语言：代码和领域中使用相同的术语
2. 限界上下文：边界清晰，模型独立
3. 上下文映射图：记录关系
4. 防腐层：保护领域完整性
5. 事件驱动：通过事件实现松耦合
6. 独立数据库：每个上下文拥有自己的数据

输出检查清单

• 已识别限界上下文（3-7 个）
• 核心领域与支撑领域
• 为每个上下文定义通用语言
• 实体/聚合定义
• 上下文关系图
• 依赖关系图
• 已定义接口契约
• 已设计防腐层
• 重构建议
• 迁移策略