microwind/ai-skills/bounded-context

同一个"商品"在不同上下文的含义：
 
┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│   商品目录上下文   │  │   库存上下文      │  │   订单上下文      │
│                  │  │                  │  │                  │
│ Product:         │  │ StockItem:       │  │ OrderItem:       │
│  - name          │  │  - sku           │  │  - productId     │
│  - description   │  │  - quantity      │  │  - price         │
│  - images        │  │  - warehouse     │  │  - quantity      │
│  - categories    │  │  - reorderPoint  │  │  - discount      │
│  - price         │  │                  │  │                  │
└──────────────────┘  └──────────────────┘  └──────────────────┘
 
每个上下文只关心自己需要的属性和行为

// 销售上下文中的 Product
package com.shop.catalog;
 
public class Product {
    private ProductId id;
    private String name;
    private String description;
    private List<Image> images;
    private Money price;
    private List<Category> categories;
 
    public void updatePrice(Money newPrice) { /* 定价逻辑 */ }
    public void publish() { /* 上架逻辑 */ }
}
 
// 库存上下文中的"商品" — 完全不同的模型
package com.shop.inventory;
 
public class StockItem {
    private String sku;
    private int quantity;
    private String warehouseId;
    private int reorderPoint;
 
    public void reserve(int amount) { /* 预留库存 */ }
    public boolean needsReorder() { return quantity <= reorderPoint; }
}
 
// 订单上下文中的"商品" — 又不同
package com.shop.order;
 
public class OrderLine {
    private String productId;  // 仅引用ID
    private Money unitPrice;   // 下单时的价格快照
    private int quantity;
 
    public Money subtotal() { return unitPrice.multiply(quantity); }
}

# ✅ 每个上下文独立的模型
# 用户上下文：关注认证
class User:  # auth context
    def __init__(self, user_id, email, password_hash):
        self.user_id = user_id
        self.email = email
        self.password_hash = password_hash
    def verify_password(self, password): ...
    def change_password(self, old, new): ...
# 客户上下文：关注个人信息
class Customer:  # customer context
    def __init__(self, customer_id, name, shipping_address, phone):
        self.customer_id = customer_id
        self.name = name
        self.shipping_address = shipping_address
    def update_address(self, new_address): ...
# 同一个人，不同上下文，不同模型

识别方法：
 
1. 语言边界：同一个词在不同场景含义不同
   "账户" → 认证上下文（登录凭证）vs 财务上下文（资金账户）
 
2. 团队边界：不同团队负责不同业务
   订单团队、支付团队、物流团队
 
3. 业务流程边界：不同的业务流程
   下单流程、支付流程、退货流程
 
4. 数据一致性边界：需要强一致性的范围
   一个上下文内强一致，上下文间最终一致

1) 集结领域专家 + 开发 + 产品，准备一面白板与三色便签
 
2) 橙色便签：写下所有"已发生的业务事件"（过去时）
   例：订单已提交、库存已扣减、支付已完成、发货已创建
   不要解释、不要排序，先穷举
 
3) 沿时间轴把事件排成"故事线"
   争议点（同一事件多人理解不一致）= 隐藏的术语边界
 
4) 蓝色便签：标注触发事件的"命令"（动词）
   黄色便签:标注命令的"参与者/聚合根候选"
 
5) 用粗黑线圈出"语言突变"的位置——同一名词含义切换处
   每一个圈 = 一个候选限界上下文
 
6) 命名每个上下文 + 写出各自最重要的 3–5 个术语
   这些术语就是该上下文的通用语言种子

// 防腐层（ACL）：在边界处做模型转换，避免外部概念污染本上下文
public class InventoryAntiCorruptionLayer {
    private final InventoryServiceClient client;
 
    public boolean isAvailable(String productId, int quantity) {
        // 调用库存上下文的 API
        StockResponse response = client.checkStock(productId);
        // 转换为本上下文的概念
        return response.getAvailableQty() >= quantity;
    }
}
 
// 或通过领域事件异步通信
// 库存上下文发布事件
public class StockDepletedEvent {
    private String sku;
    private String warehouseId;
}
 
// 订单上下文订阅并处理
@EventHandler
public void onStockDepleted(StockDepletedEvent event) {
    // 标记相关商品为不可购买
}