3.5.1 DDD 战略设计 · 限界上下文 / 上下文映射

1. 为什么这个专题重要

微服务拆错的根因,90% 都不在「用什么 RPC / 怎么容器化 / Service Mesh 选型」这些战术层面,而在战略阶段没做 DDD。

业务方提需求的时候,通常说的是「订单」「商品」「库存」「用户」这些大词。技术同学一接到手,就按字面意思拆 4 个微服务,代码里继续用一个 Order 类、一个 User 表贯穿全系统。半年后,跨服务调用链混乱、改一个字段动 5 个仓库、单元测试跑不起来 —— 这就是典型的「战术很努力,战略没做」。

业务复杂度上升时的必然选择:

• 单体应用早期,一个 User 模型走天下没问题,反正都在一个进程里;
• 团队过了 15 人、代码过了 30 万行,同一个词在不同模块含义不同,「翻译损耗」开始吞噬生产力;
• 业务进入多 BU、多产品线,同一个「商品」在 C 端是 SKU,在仓配是 SKU + 库位,在财务是 SKU + 成本中心 —— 一份模型扛不住了。

DDD(Domain-Driven Design,领域驱动设计)的战略设计就是在动手写代码前,先回答三个问题:

1. 业务里到底有几个子域(Subdomain)?哪些是核心,哪些是支撑?
2. 每个子域的限界上下文(Bounded Context)边界画在哪?边界内谁负责?
3. 上下文之间怎么映射(Context Map)?谁依赖谁、谁翻译谁?

Eric Evans 在 2003 年出版的《Domain-Driven Design》中,用了全书 1/3 篇幅讲战略设计;Vaughn Vernon 在《Implementing DDD》(2013)和《DDD Distilled》(2016)中进一步强调:战略模式比战术模式(实体/值对象/聚合根)重要 10 倍。

2. DDD 战略设计全景

战略设计的 4 大核心概念,初学者最容易混。先一张表对比清楚:

2.1 四者关系(自上而下)

flowchart LR
    A[业务愿景] --> B[子域划分]
    B --> C[限界上下文]
    C --> D[上下文映射]
    D --> E[通用语言]
    E -.->|持续反馈| A

逐层关系:

1. 子域是问题的视角 ——「我们要做电商,里面分几块生意?」
2. 限界上下文是解的视角 ——「这块生意,谁来负责?边界画在哪?」
3. 上下文映射是协作的视角 ——「他们之间怎么打交道?谁听谁的?」
4. 通用语言是沟通的视角 ——「『订单』在这两边都是同一个意思吗?」

2.2 战略 vs 战术

flowchart LR
    subgraph Strategic[战略设计 Strategic]
        S1["子域 / 限界上下文 / 上下文映射"]
        S2["通用语言"]
        S3["团队拓扑 (Team Topologies)"]
        S4["服务拆分 / 数据所有权"]
        S5["影响:组织架构、招聘计划"]
        S6["时间维度:季度 ~ 年"]
    end
    subgraph Tactical[战术设计 Tactical]
        T1["实体 / 值对象 / 聚合根"]
        T2["领域服务 / 领域事件"]
        T3["仓储 / 工厂 / 规约"]
        T4["CQRS / Event Sourcing"]
        T5["影响:代码组织、单元测试"]
        T6["时间维度:周 ~ 月"]
    end

实战经验:战略错了,战术再精也是白搭;反过来,战略对了但战术落地一塌糊涂(比如限界上下文画得好,但代码里全是贫血模型),也会失败。本专题专注战略,战术留给 3.5.2。

3. 子域划分详解

子域(Subdomain)是对业务能力的切分。DDD 把子域分成 3 类,按投资优先级和团队投入排序:

3.1 三类子域详解

核心域 (Core Domain)

• 是企业赖以生存的能力,是商业模式的核心,直接产生商业价值。
• 投入逻辑:用最好的工程师、最长的时间、最深度的业务理解去做。
• 例子:Netflix 的推荐算法、淘宝的搜索/推荐/交易撮合、Salesforce 的 CRM 自动化。

支撑域 (Supporting Subdomain)

• 业务必须做,但本企业做得不如别人也不致命的能力。
• 投入逻辑:自建能匹配业务节奏即可,不必追求极致优雅。
• 例子:大多数公司的「售后服务系统」「内部 OA 流程」。

通用域 (Generic Subdomain)

• 行业里都有成熟方案,直接买或用开源比自己做便宜 10 倍。
• 投入逻辑:能 SaaS 就 SaaS,能开源就开源,能不写代码就不写代码。
• 例子:邮件发送、短信推送、文件存储、身份认证 (OAuth/JWT)、支付通道对接的胶水层。

3.2 电商系统子域划分案例

以一个中等规模电商(自营 + 三方商家)为例,完整子域划分:

注意:同一个业务词在不同企业可能是不同子域 ——「支付」在支付宝是核心域,在普通电商是支撑域;「用户账户」在微信是核心域,在大多数 SaaS 是支撑域。

3.3 子域识别工作流

# 子域识别工具:给每个候选能力打分,辅助判定类型
from dataclasses import dataclass
from enum import Enum


class SubdomainType(Enum):
    CORE = "核心域"
    SUPPORTING = "支撑域"
    GENERIC = "通用域"


@dataclass
class SubdomainCandidate:
    name: str                           # 子域名,如 "商品推荐"
    business_criticality: int           # 1-5,业务关键度
    differentiation: int                # 1-5,差异化程度
    external_maturity: int              # 1-5,外部成熟方案多寡
    description: str = ""

    def classify(self) -> SubdomainType:
        """
        简单启发式:
        - 关键度高 + 差异高 → 核心域
        - 关键度高 + 差异低 + 外部成熟度低 → 支撑域
        - 关键度低 或 外部成熟度高 → 通用域
        """
        if self.business_criticality >= 4 and self.differentiation >= 4:
            return SubdomainType.CORE
        if self.business_criticality >= 3 and self.external_maturity <= 2:
            return SubdomainType.SUPPORTING
        return SubdomainType.GENERIC


# 实战打分
candidates = [
    SubdomainCandidate("商品推荐", 5, 5, 1),
    SubdomainCandidate("订单交易", 5, 4, 2),
    SubdomainCandidate("营销促销", 4, 5, 2),
    SubdomainCandidate("支付清算", 4, 2, 4),    # 关键但有支付宝
    SubdomainCandidate("邮件短信", 2, 1, 5),    # 直接买
]
for c in candidates:
    print(f"{c.name:8s} → {c.classify().value}")

运行结果:商品推荐 → 核心域、订单交易 → 核心域、营销促销 → 核心域、支付清算 → 支撑域、邮件短信 → 通用域。

4. 限界上下文详解

限界上下文(Bounded Context)是 Eric Evans 给出的核心定义:

一个边界内模型完全一致,边界外模型不必一致。 —— Eric Evans,《Domain-Driven Design》2003

每个限界上下文 = 一个自治的领域模型 + 一个独立的代码库 + 一个独立部署的进程 + 一个负责的团队。这是 Conway 定律(组织决定架构)的正面运用。

4.1 为什么一定要画边界

没有限界上下文的典型灾难:同一个词「订单」在 A 模块是 Order(id, items, user_id),在 B 模块是 Order(id, items, user, address, status, ...),在 C 模块又是 OrderDTO(id, sku_list, ...),三套字段、三套含义、三套人维护。任何一个业务变更都得改三个地方,任何一处改错,全链路挂掉。

限界上下文强制每个团队自己定义自己范围内的概念,跨边界时通过明确的接口协议(API / 事件 / 共享内核)交互,不偷对方的模型。

4.2 边界划分的 4 个信号

判断一个限界上下文边界是否合理,看这 4 个信号:

反过来,反过来——以下征兆往往说明边界画错了:

• 一个 PR 经常要改 3 个仓库 → 上下文划分过粗,应该拆;
• 一个团队同时维护 5 个上下文,但每个上下文每周只改一点 → 上下文过细,应该合并;
• 跨上下文 join 满天飞 → 数据所有权没分清,应该先治理数据,再调边界。

4.3 限界上下文示例:订单 + 库存 + 用户

下面用 Python dataclass 演示 3 个限界上下文的领域模型,注意同样的名词在不同上下文里是不同的类。

# ─── 限界上下文 1:订单上下文 (Order Context) ─────────────────
# 关注:订单的创建、状态流转、金额计算
# 团队:交易团队(订单组)

from dataclasses import dataclass, field
from datetime import datetime
from decimal import Decimal
from enum import Enum


class OrderStatus(Enum):
    CREATED = "已创建"
    PAID = "已支付"
    SHIPPED = "已发货"
    COMPLETED = "已完成"
    CANCELLED = "已取消"


@dataclass
class OrderItem:
    sku_id: str                              # 这里只引用 sku_id,不持有库存细节
    quantity: int
    unit_price: Decimal


@dataclass
class Order:
    order_id: str
    buyer_id: str                            # 用户上下文里的 ID,本上下文不解析
    items: list[OrderItem]
    status: OrderStatus
    total_amount: Decimal
    created_at: datetime
    # 注意:订单上下文里没有 user_name / address / stock_quantity
    # 这些字段属于其他上下文

    def pay(self) -> None:
        if self.status != OrderStatus.CREATED:
            raise ValueError(f"订单 {self.order_id} 当前状态 {self.status} 不可支付")
        self.status = OrderStatus.PAID

# ─── 限界上下文 2:库存上下文 (Inventory Context) ──────────────
# 关注:仓库、库位、可用库存、预占、扣减
# 团队:仓配团队(库存组)
# 注意:同样叫 sku_id,但这里关心的是「库位 + 库存」

from dataclasses import dataclass


@dataclass
class WarehouseLocation:
    warehouse_id: str
    shelf: str


@dataclass
class StockUnit:
    sku_id: str
    location: WarehouseLocation
    on_hand: int               # 在库数量
    available: int             # 可用数量(=on_hand - reserved)
    reserved: int = 0          # 已预占数量

    def reserve(self, qty: int) -> None:
        if qty > self.available:
            raise ValueError(f"sku {self.sku_id} 库存不足")
        self.reserved += qty
        self.available -= qty


@dataclass
class InventoryReservation:
    """库存预占单:由订单上下文触发,库存上下文内部状态"""
    reservation_id: str
    order_id: str              # 跨上下文引用:订单上下文 ID
    sku_id: str
    quantity: int
    released: bool = False

# ─── 限界上下文 3:用户上下文 (User Context) ──────────────────
# 关注:用户身份、会员等级、收货地址
# 团队:用户增长团队

from dataclasses import dataclass
from enum import Enum


class MembershipLevel(Enum):
    BRONZE = "青铜"
    SILVER = "白银"
    GOLD = "黄金"
    DIAMOND = "钻石"


@dataclass
class Address:
    province: str
    city: str
    detail: str
    zipcode: str


@dataclass
class User:                      # 注意:这里的 User 和订单/库存的 buyer_id 是同一个 ID
    user_id: str
    nickname: str
    phone: str
    level: MembershipLevel
    default_address: Address | None = None

    def is_premium(self) -> bool:
        return self.level in (MembershipLevel.GOLD, MembershipLevel.DIAMOND)

4.4 关键原则回顾

• 同一概念在不同上下文里可以有不同模型(同 User,不同字段);
• 跨上下文引用只用 ID(buyer_id / order_id),不直接持有对方对象;
• 每个上下文有自己独立的数据库 schema,跨库 join 是反模式;
• 上下文之间的交互只能通过明确的接口(API 调用或领域事件)。

5. 上下文映射 9 大模式

上下文映射(Context Map)是 Eric Evans 在《DDD》第 3 章明确列出的 9 种上下文之间的协作模式。每种模式回答的是:「A 上下文和 B 上下文之间,谁负责、谁翻译、谁妥协、谁独立?」

5.1 9 大模式对比表

参考:Vaughn Vernon《Implementing DDD》第 3 章对这 9 种模式有完整展开;Nick Tune《Architecture Patterns with Python》和微服务战略设计博客也给出了每种模式的工程实现。

5.2 9 大模式的 ASCII 全景图

flowchart TD
    P["Partnership 伙伴<br/>两个上下文对等,共同演进"]
    SK["Shared Kernel<br/>共享内核"]
    CS["Customer-Supplier<br/>客户-供应商"]
    CF["Conformist 遵奉者<br/>下游吞上游模型"]
    ACL["Anti-Corruption Layer (ACL)<br/>下游用翻译层保护自己"]
    OHS["Open-Host Service (OHS)<br/>+ Published Language<br/>上游稳定公开 API<br/>用 JSON Schema / Avro"]
    SW["Separate Ways 各行其道<br/>不集成,各自实现"]
    BBoM["Big Ball of Mud 大泥球<br/>反模式!需要治理"]

    P --> CF
    SK --> CF
    CS --> CF
    CF --> ACL
    ACL --> OHS
    OHS --> SW
    SW --> BBoM

    classDef antiPattern fill:#ffd6d6,stroke:#c00,color:#900
    class BBoM antiPattern

5.3 实战代码:ACL 翻译层示例

ACL(Anti-Corruption Layer,防腐层)是实战中用得最多的模式。当对接外部系统(老 ERP、第三方支付、遗留 CRM)时,翻译层保护本地上下文不被污染。

# ─── 场景:订单上下文对接遗留 ERP 的「商品主数据」接口 ────────
# 问题:ERP 返回的模型字段命名不规范、含 ERP 内部概念、字段类型是奇怪的格式
# 解法:在订单上下文里写一层 ACL,把 ERP 模型翻译成本地 Product

from dataclasses import dataclass
from decimal import Decimal
from abc import ABC, abstractmethod


# ── 本地上下文模型:订单上下文关心的「商品」 ──
@dataclass(frozen=True)
class Product:
    sku_id: str
    name: str
    category: str
    unit_price: Decimal

# ── 外部 ERP 的原始数据格式(脏数据) ──
@dataclass
class LegacyErpProductDTO:
    MATNR: str                    # ERP 物料号 = 我们的 sku_id
    MAKTX: str                    # 物料描述
    MATKL: str                    # 物料组
    VKPE: str                     # 销售价格,ERP 用字符串 "12.50 EUR"
    LIFNR: str                    # 供应商号(订单上下文不需要)
    WERKS: str                    # 工厂号(订单上下文不需要)
    AEDAT: str                    # 最后修改日期 "20260115"


# ── ACL 翻译层:把 ERP 字段翻译成本地 Product ──
class ProductTranslator:
    """
    Anti-Corruption Layer 的职责:
    1. 字段名转换(MATNR → sku_id)
    2. 类型转换(VKPE 字符串 → Decimal + 提取币种)
    3. 丢弃不需要的字段(LIFNR / WERKS)
    4. 异常值兜底(价格缺失、币种不支持)
    """

    SUPPORTED_CURRENCIES = {"EUR", "USD", "CNY"}

    def translate(self, erp: LegacyErpProductDTO) -> Product:
        amount, currency = self._parse_price(erp.VKPE)
        if currency not in self.SUPPORTED_CURRENCIES:
            raise ValueError(f"ERP 返回了不支持的币种: {currency}")
        return Product(
            sku_id=erp.MATNR.strip(),
            name=erp.MAKTX.strip(),
            category=self._normalize_category(erp.MATKL),
            unit_price=amount,
        )

    def _parse_price(self, raw: str) -> tuple[Decimal, str]:
        # ERP 返回 "12.50 EUR" → (Decimal("12.50"), "EUR")
        parts = raw.strip().split()
        if len(parts) != 2:
            raise ValueError(f"ERP 价格格式异常: {raw!r}")
        return Decimal(parts[0]), parts[1]

    def _normalize_category(self, matkl: str) -> str:
        # ERP 物料组是 4 位编码,本地用业务术语
        mapping = {
            "0001": "服饰",
            "0002": "美妆",
            "0003": "数码",
            "0004": "食品",
        }
        return mapping.get(matkl, "其他")

# ── ACL 调用入口:订单上下文通过 ACL 访问 ERP,不直接 import ERP 模型 ──
class ProductQueryService(ABC):
    @abstractmethod
    def get_by_sku(self, sku_id: str) -> Product: ...


class ErpBackedProductQueryService(ProductQueryService):
    """ACL 的「出站适配器」:订单上下文只依赖 ProductQueryService 接口"""

    def __init__(self, erp_client, translator: ProductTranslator):
        self._erp = erp_client
        self._translator = translator

    def get_by_sku(self, sku_id: str) -> Product:
        raw = self._erp.fetch_product(sku_id)            # 返回 LegacyErpProductDTO
        return self._translator.translate(raw)           # 翻译成本地 Product


# ── 订单上下文使用 ──
# 不再出现 ERP 的 MATNR / VKPE / LIFNR,本地上下文模型纯净
service: ProductQueryService = ErpBackedProductQueryService(erp_client, ProductTranslator())
product = service.get_by_sku("SKU-12345")
print(product.unit_price, product.category)             # 12.50 服饰

ACL 的关键工程纪律:

• 不跨层 import:订单上下文代码里不能 from legacy.erp import LegacyErpProductDTO;
• 翻译逻辑集中:所有 ERP → 本地的转换都在 ProductTranslator,便于单测;
• 接口在前,实现在后:先定义本地的 ProductQueryService 接口,再写 ACL 实现。

6. 通用语言(Ubiquitous Language)详解

通用语言(Ubiquitous Language)是 Eric Evans 在《DDD》第 2 章就抛出的核心概念:

业务方与技术方在同一个词上达成一致,代码、文档、对话、UI 全用同一套术语。

通用语言不是技术名词翻译表,不是「User=用户」这种字典;它是团队 + 业务方共用的概念体系,每个概念有明确的边界、状态、规则。

6.1 没有通用语言的典型症状

• 业务方说「订单关闭」,技术方做的是「取消订单」,其实业务方指的是 7 天未支付自动关闭的逻辑;
• 产品文档写「购物车」,代码里类名是 CartBasket,UI 上写的是「我的购物篮」;
• 业务群里讨论「退款」,开发问「是原路退回还是退到余额?」 —— 业务自己也没说清。

这些翻译损耗(translation loss)累积起来,就是开发返工 + 业务抱怨的源头。

6.2 Event Storming 工作坊方法

Alberto Brandolini 在 2013 年提出的 Event Storming 是当前公认的「最快建立通用语言」的工作坊方法。

核心规则:

• 全员参与:开发、测试、产品、业务、运营、客服;
• 物理墙 + 便利贴(或 Miro 在线白板);
• 用橙色的领域事件(过去时态)作为主线:OrderPlaced、PaymentReceived、GoodsShipped;
• 时间轴从左到右铺开;
• 黄色便利贴 = 命令(触发事件的命令)、蓝色 = 角色(谁触发)、紫色 = 政策/规则;
• 粉色 = 外部系统(需要 ACL 翻译);
• 绿色 = 读模型(查询视图)。

流程(通常 1-2 天):

flowchart LR
    A["Morning Day 1<br/>全员梳理:业务目标、关键事件(橙)、命令(黄)"]
    B["Afternoon Day 1<br/>识别触发角色(蓝)、外部系统(粉)、关键政策(紫)"]
    C["Morning Day 2<br/>找限界上下文边界:事件成簇 = 一个上下文"]
    D["Afternoon Day 2<br/>标注上下文映射、识别核心域"]
    E["Wrap-up<br/>整理术语表、输出 Context Map 图"]
    A --> B --> C --> D --> E

Event Storming 的副产品:

1. 通用语言术语表(从便利贴上的命名提炼);
2. 限界上下文草图(事件簇 = 上下文边界);
3. 领域事件清单(直接对应消息队列或 Outbox 表的事件);
4. 跨上下文集成点(橙色便利贴跨越上下文边界的位置 = 集成点)。

6.3 订单域通用语言术语表(20 个核心术语)

下表是订单限界上下文的通用语言术语表示例。注意:每个词都有明确定义,没有歧义。

6.4 通用语言落地检查清单

通用语言不是开一次会、写一份文档就完事,工程上要做这些:

• 命名严格对齐:类名、变量名、数据库表名、API 字段名、UI 文案,全部用通用语言术语;
• 字典集中维护:术语表放在仓库 docs/ubiquitous-language/<context>.md,PR 修改需评审;
• 新人 onboarding 第一课:通用语言 + Context Map;
• 业务方评审 UI 文案时,技术方拿术语表对照;
• 定期回顾:每季度一次,业务方和技术方一起过一遍术语表。

7. 实战案例 4 个

7.1 案例 1:电商系统子域划分

某自营 + 三方商家混合的电商,GMV ~50 亿/年,研发 ~300 人。

子域划分结果:

flowchart TD
    CORE["核心域 (60% 研发投入)<br/>商品推荐 / 个性化搜索 / 订单交易 / 营销促销"]
    SUP["支撑域 (30% 研发投入)<br/>支付清算 / 仓配物流 / 用户账户 / 售后服务"]
    GEN["通用域 (10% 研发投入)<br/>邮件 / 短信 / 文件存储 / 身份认证 / 风控基础"]

    classDef coreStyle fill:#ffd6a5,stroke:#c70,stroke-width:2px,color:#600
    classDef supStyle fill:#d0e8ff,stroke:#06c,color:#036
    classDef genStyle fill:#e0e0e0,stroke:#888,color:#333

    class CORE coreStyle
    class SUP supStyle
    class GEN genStyle

关键决策点:

• 「商品推荐」是核心域:虽然短期 ROI 不直观,但它是 GMV 增长的杠杆,直接决定平台留存;
• 「支付清算」是支撑域:有微信/支付宝/银联成熟通道,自建只做路由 + 对账,不碰核心账务处理;
• 「邮件/短信」是通用域:直接采购 SendCloud + 阿里云短信,自研只会拖慢业务节奏。

教训:早期把「物流调度」当核心域,投入了 40 人做了 1 年,结果业务方说「顺丰和京东已经做得很好了,我们接他们的 API 就行」。这次教训后,「我们是不是真核心」成为每个子域上线的灵魂拷问。

7.2 案例 2:跨国业务多语言限界上下文

某跨境电商,中国/欧洲/美国三地运营,共用一套商品主数据 + 订单交易,但各国合规、支付、税务完全不同。

三套限界上下文:

ACL 翻译层设计:

• 商品主数据是上游,通过 Published Language(Avro Schema)发布 ProductPublished 事件;
• 三个国家的 Order 上下文各自用 ACL 把 Product 翻译成本地 LocalizedProduct(价格换币种 + 含税/不含税 + 法规要求的标签如欧洲 CE 标志);
• 三套 Order 上下文之间用 Separate Ways,不直接集成 —— 它们规则差异太大,共享反而是负担。

实战收益:GDPR 上线时,只改 OrderEU 一个上下文,其他两个上下文完全不受影响。这就是限界上下文的真正价值:把变化隔离开。

7.3 案例 3:Event Storming 工作坊实战

某金融科技公司启动「供应链金融」业务,全新的领域,2019 年初组织了一次 Event Storming。

准备工作坊:

• 30 人参与:业务总监 2、风控经理 3、产品经理 5、研发组长 8、架构师 2、运维 2、客服 2、外部银行对接 6;
• 整面 12 米长墙,3 种颜色的便利贴(橙/黄/蓝/紫/粉/绿)共 1500 张;
• 时长 2 天(8h × 2 = 16h);
• 主持人 2 名(架构师 + 业务总监),Alberto Brandolini 的视频先放 30 分钟铺垫共识。

Day 1 产出:约 380 个领域事件(橙)、260 个命令(黄)、140 个角色(蓝)、80 个政策(紫)、40 个外部系统(粉)。

Day 2 产出:

1. 12 个限界上下文(把事件成簇归并):客户管理、授信申请、风险评估、合同签署、放款管理、还款计划、资金账户、对账清算、商户管理、产品配置、运营报表、对客通知;
2. 核心域识别:风险评估 + 放款管理是核心域(差异化竞争力);
3. Context Map:13 条上下文映射关系,标注了 ACL / OHS / Conformist / Separate Ways 4 种模式;
4. 领域事件 200+ 收敛到 80+:删除重复、合并细粒度事件;
5. 术语表初稿 120 词。

3 个月后回顾:架构师说「这次工作坊节省了至少 3 个月的返工时间」。代价是 2 天全员停工,价值远超成本。

7.4 案例 4:遗留系统 DDD 重构

某零售 ERP,2010 年 Java + Struts2 单体,代码 80 万行,4 个团队维护,典型的 Big Ball of Mud。

症状:

• 一个「商品」类 1200 行,被 30 多个模块引用;
• 改一个字段要发 15 个文件;
• 上线一次回归测试要 200 人天;
• 每月 2 次 P0 故障,全是跨模块耦合导致。

18 个月 DDD 重构路径:

结果:

• 平均迭代周期从 4 周降到 1 周;
• 单服务最大代码量 12 万行,可独立部署;
• P0 故障率从 2/月降到 0.3/月;
• 团队从「谁都不敢动」变成「每个服务都有明确 owner」。

最大教训:Phase 0 高层对齐花了 2 个月,看起来慢,实际是后面 16 个月能跑顺的前提。没有高层对 DDD 价值的认可,战略阶段就会被业务方反复 challenge。

8. 选型决策树 + 9 维度对比表

8.1 限界上下文划分决策树

flowchart TD
    START(["业务复杂度评估"])
    SIMPLE{"单一业务线<br/>< 15 研发"}
    MULTI{"多业务线<br/>≥ 15 研发"}
    ONE_CTX["1 个限界上下文即可<br/>(Monolith 也合理)"]
    WORKSHOP["Event Storming 工作坊<br/>识别子域 + 上下文"]
    SUB_LE3{"子域 ≤ 3 个"}
    SUB_GT3{"子域 > 3 个"}
    MAPPING["上下文 1:1 对应子域即可"]
    SIG["按以下 4 信号再切"]
    OUT["输出 Context Map v1<br/>标注 9 大映射模式"]

    S1["信号 1:团队结构<br/>一个 BC = 一个团队"]
    S2["信号 2:业务能力<br/>一句话说清职责"]
    S3["信号 3:数据所有权<br/>独立 Schema"]
    S4["信号 4:性能/合规<br/>SLO 差异显著"]

    START --> SIMPLE
    START --> MULTI
    SIMPLE -->|是| ONE_CTX
    MULTI -->|是| WORKSHOP
    WORKSHOP --> SUB_LE3
    WORKSHOP --> SUB_GT3
    SUB_LE3 -->|是| MAPPING
    SUB_GT3 -->|是| SIG
    SIG --> S1
    SIG --> S2
    SIG --> S3
    SIG --> S4
    S1 --> OUT
    S2 --> OUT
    S3 --> OUT
    S4 --> OUT

8.2 9 维度对比表:什么时候用 DDD 战略设计

判断口诀:团队过 15 人、代码过 30 万行、需求迭代周级 —— 三条满足两条,就该上 DDD 战略设计。

8.3 9 大上下文映射模式选型决策

flowchart TD
    Q1{"上游有没有动力配合?"}
    Q2{"团队能否共建?"}
    Q3{"下游要保护自己的模型?"}
    Q4{"多个下游要用?"}
    Q5{"集成成本 > 重复实现?"}
    PART["Partner"]
    CS["Customer-Supplier"]
    ACL_["ACL"]
    CON["Conformist"]
    OHS_PL["OHS +<br/>Published Language"]
    SK["Shared Kernel"]
    SW["Separate Ways"]

    Q1 -->|有| Q2
    Q1 -->|没有| Q3
    Q2 -->|是| PART
    Q2 -->|否| CS
    Q3 -->|是| ACL_
    Q3 -->|否| CON
    ACL_ --> Q4
    Q4 -->|是| OHS_PL
    Q4 -->|否| SK
    Q5 -->|是| SW

8.4 战略设计投入产出比模型

# 一个简单的判断工具:什么时候值得做完整的 DDD 战略设计
@dataclass
class ProjectContext:
    team_size: int                # 团队规模
    code_lines: int               # 代码行数(万)
    services_count: int           # 微服务数
    business_change_freq: str     # "monthly" / "weekly" / "daily"
    compliance_required: bool     # 是否有强合规

    def recommend_ddd_strategic(self) -> tuple[bool, str]:
        """
        简单的评分:满足 ≥ 3 条触发 DDD 战略设计
        """
        score = 0
        reasons = []
        if self.team_size >= 15:
            score += 1; reasons.append(f"团队 {self.team_size} ≥ 15")
        if self.code_lines >= 30:
            score += 1; reasons.append(f"代码 {self.code_lines} 万 ≥ 30 万")
        if self.services_count >= 5:
            score += 1; reasons.append(f"微服务 {self.services_count} ≥ 5")
        if self.business_change_freq in ("weekly", "daily"):
            score += 1; reasons.append(f"变更频率 {self.business_change_freq}")
        if self.compliance_required:
            score += 1; reasons.append("强合规")

        if score >= 3:
            return True, "建议做完整 DDD 战略设计(Event Storming + Context Map)"
        elif score >= 2:
            return False, "建议做轻量 DDD(术语表 + 限界上下文草图)"
        else:
            return False, "暂不需 DDD,先解决业务问题"

9. 踩坑 6 个

坑 1:核心域识别错(把通用域当核心域)

症状:团队花 8 个月自研「邮件触达平台」,投入 4 人,完成后业务方说「我们其实用 SendCloud + SendGrid 就够了,为什么要自研?」

原因:核心域识别只看「技术含量」,不看「商业差异化」。「邮件发送」技术上涉及模板、批量、退避、追踪,看起来很复杂,但所有邮件 SaaS 都解决了,差异化是 0。

修法:

• 用 3.3 节的 SubdomainCandidate.classify() 打分,关键度和差异化都 ≥ 4 才算核心域;
• 灵魂拷问:「竞品做不出这个,还是竞品不愿做?」前者是核心,后者是支撑;
• 通用域直接采购,不自研;支撑域自建够用即可。

正确代码:

# 邮件 → 通用域:接 SendCloud,不自研
class NotificationGateway:
    def __init__(self, provider_client):          # SendCloud / SendGrid
        self._client = provider_client
    def send_email(self, to, template_id, params): ...
    def send_sms(self, phone, template_id, params): ...

# 不写 send_email(template: Template, ...) 这套复杂抽象,通用域不值得

坑 2:限界上下文过细(1 个业务拆 10 个上下文)

症状:「订单」拆成 OrderCreate / OrderPay / OrderShip / OrderRefund / OrderCancel / OrderComplete / OrderQuery / OrderAddress / OrderItem / OrderPromotion 10 个上下文,跨上下文调用链 13 跳,一次下单耗时 +200ms。

原因:「微服务 = 一个动词」 的错误认知,把业务动作当成了上下文边界。

修法:

• 一个限界上下文应该封装一个完整的业务能力,不是一组操作;
• 一句话说清职责说清楚才能拆:「订单上下文负责订单从创建到完成的全生命周期」;
• 上下文中按业务能力拆,不按操作拆;
• 单团队 < 8 人的,通常 3-7 个上下文足够,超过 10 个就要合并。

正确拆分:

flowchart LR
    subgraph BAD["❌ 错误:10 个上下文 (跨调用 13 跳)"]
        B1["OrderCreate"]
        B2["OrderPay"]
        B3["OrderShip"]
        B4["..."]
    end

    subgraph GOOD["✅ 正确:1 个订单上下文 + 5 个领域服务 (进程内调用 0 跳)"]
        G["OrderContext<br/>- 实体:Order/OrderItem<br/>- 服务:Pricing/Shipping<br/>- 事件:OrderPlaced/Paid"]
    end

    classDef badStyle fill:#ffe0e0,stroke:#c00,color:#900
    classDef goodStyle fill:#d8f0d8,stroke:#080,color:#040
    class B1,B2,B3,B4 badStyle
    class G goodStyle

坑 3:共享内核过大(Shared Kernel 包罗万象)

症状:某团队为了「减少重复」建了一个 common-kernel 包,塞进了 50 多个实体类(User/Order/Product/Address/Money/…),每个微服务都依赖这个包,改一个字段 20 个服务一起改。

原因:把「共享内核」当成了「公共 util 包」,混淆了 Kernel 和 Util 的边界。

修法:

• Shared Kernel 只放「双方都强相关且变更必须同步」的概念,比如订单-支付的 Money 类型、订单-库存的 SkuId 类型;
• 其他跨上下文通用概念,放发布语言(Published Language,如 Avro Schema)或防腐层 ACL,不放 Kernel;
• 一个 Shared Kernel 通常 < 5 个核心类型,超过就要拆。

正确做法:

# shared_kernel/order_payment_common.py —— 只放真正共用的
@dataclass(frozen=True)
class Money:
    amount: Decimal
    currency: str            # ISO 4217

@dataclass(frozen=True)
class SkuId:
    value: str

# 严禁把 Order/User/Product 放进来 —— 那些是各自上下文的核心模型

坑 4:ACL 翻译层偷懒(直接拷贝外部模型)

症状:订单上下文代码里写 from erp.legacy import MATNR,全代码飘着 ERP 的德语字段命名,业务同学看不懂。

原因:觉得「写一层翻译浪费时间」「反正字段就那几个」。结果:ERP 改个字段名,本地全炸;业务方讨论「订单里的商品」时,技术说「MATNR」「MAKTX」,根本对不上话。

修法:

• ACL 必须有显式翻译类,字段一一映射,不能省;
• 翻译逻辑必须有单元测试,ERP 字段变更时单测立刻爆,提醒本地;
• 本地上下文代码严禁 import 外部包的任何具体类,只能 import 自己的领域模型。

错误示例:

# 错:直接用 ERP 模型
from erp.legacy import MATNR
def create_order(sku: MATNR, qty: int):  # ← 本地代码不应该出现 MATNR
    ...

正确示例:见 5.3 节的 ProductTranslator + ErpBackedProductQueryService。

坑 5:通用语言只停留在文档

症状:文档里写「订单(Order)」,代码里却是 OrderEntity,UI 上是「我的订单」,数据库表是 t_trade_main,3 个名字,3 个意思。业务方说「订单关闭」,技术做的是 Order.cancel(),行为不一致。

原因:把「通用语言」当作文档工作,没有约束到代码层。文档和代码两张皮,术语表很快过期。

修法:

• 强制命名约束:类名、表名、API 字段名、UI 文案,与术语表 100% 对齐;
• PR 评审检查:Reviewer 看到 t_trade_main 这种「不在术语表」的命名,直接打回;
• CI 检查:写一个 lint 脚本扫 PR 变更的类名/表名,与术语表比对,不一致就 fail;
• 术语表放在仓库 docs/ubiquitous-language/,PR 修改术语表需要业务方 + 技术 lead 双签。

坑 6:战略和战术脱节(战略规划很美,落地还是 CRUD)

症状:战略规划会上画了漂亮的 Context Map,12 个上下文、9 大映射模式、ACL/OHS/Published Language 都齐了。但落地时,代码里一个 GodService 包含所有 12 个上下文的业务逻辑,数据库一张大宽表,接口都是 POST /api/v1/execute,战略文档躺在 Confluence 里吃灰。

原因:战略是架构师的事,落地是开发的事,两者脱节;架构师没参与代码评审,开发没读过战略文档。

修法:

• 架构师必须参与代码评审,每月至少看 30 个 PR,看战略模式是否在代码里体现;
• 每个上下文有「战术落地 checklist」:聚合根识别、领域服务抽离、领域事件发布、ACL 翻译层实现;
• 季度战略回顾:战略规划 - 落地实现 - 实际运行,三段对照,看哪里脱节;
• 每个微服务有 OWNERS 文件,明确写出属于哪个上下文、负责什么、和其他上下文什么关系。

10. 速查表 + 口诀 + Event Storming Checklist

10.1 4 大概念速查表

10.2 9 大上下文映射模式速查表

10.3 选型口诀 3 句话

1. 核心域重兵,通用域采购,支撑域够用就好 —— 子域投资的优先级。
2. 边界画在团队,数据各归各,跨边界只传 ID —— 限界上下文落地的三大纪律。
3. 能 ACL 就 ACL,能 OHS+PL 就公开,实在不行 Separate Ways —— 上下文映射模式选型顺序。

10.4 Event Storming 工作坊 Checklist(12 项)

前期准备(4 项):

• 1. 业务方 Owner 确认 + 全员邀请(开发/测试/产品/业务/运营/客服),目标 15-30 人
• 2. 物理场地(12m 墙)或 Miro 在线白板;便利贴(橙/黄/蓝/紫/粉/绿 6 色)备齐
• 3. 主持人 2 名(架构师 + 业务总监),提前看 Alberto Brandolini 的视频
• 4. 业务材料预读(用户故事/竞品分析/现有流程图),提前 3 天发给大家

Day 1 上午(2 项):

• 5. 业务愿景对齐:所有人用 5 分钟写下「我们做这件事要解决什么问题」
• 6. 全员贴事件:从「第一个触发业务的事件」到「最后一个终结事件」,橙便利贴贴满整面墙

Day 1 下午 + Day 2 上午(3 项):

• 7. 补全命令(黄)、角色(蓝)、政策(紫)、外部系统(粉),所有人参与讨论命名
• 8. 找限界上下文边界:把事件成簇归并,每簇 1 个暂定名,讨论边界
• 9. 标注 Context Map:上下文之间的箭头 + 模式标签(ACL/OHS/Shared Kernel 等)

Day 2 下午 + 收尾(3 项):

• 10. 识别核心域:用 3.3 节打分法,标注哪些是核心/支撑/通用
• 11. 收敛产出:删除重复事件、合并细粒度、输出术语表 v1 + Context Map v1
• 12. 后续跟进:每个上下文指派 Owner + 下次工作坊日期(通常 4-6 周后回顾)

11. 调研依据(10+ 处)

1. Eric Evans,《Domain-Driven Design: Tackling Complexity in the Heart of Software》,2003 —— DDD 圣经,第 2 章通用语言,第 3 章限界上下文与上下文映射。
2. Vaughn Vernon,《Implementing Domain-Driven Design》,2013 —— 第 3 章对 Context Map 9 大模式最完整的工程化展开。
3. Vaughn Vernon,《Domain-Driven Design Distilled》,2016 —— 战略 vs 战术的浓缩版,适合高管宣讲。
4. Vaughn Vernon,《DDD Reference Card》 —— 速查卡片,本专题速查表大量参考其结构。
5. Alberto Brandolini,《Introducing Event Storming》,2013 —— Event Storming 工作坊方法的原始出处。
6. Alberto Brandolini,《Event Storming: Alleviate Chaos and Deliver Value》(视频) —— 完整 1 小时工作坊演示。
7. Sam Newman,《Building Microservices》,2nd Edition,2021 —— 微服务设计经典,Conway 定律 / 限界上下文落地的工程视角。
8. Sam Newman,《Monolith to Microservices》,2019 —— 遗留系统重构(Strangler Fig 模式)的实战指南,本专题案例 4 参考其方法。
9. Nick Tune,《Architecture Patterns with Python: Enabling Testable Architecture with Domain-Driven Design》,Cosmic Python 系列 —— DDD + Python 工程化实践。
10. Nick Tune & Jean-Georges Perrin,《Microservices Patterns for the Enterprise》,2018 —— 跨国业务多语言限界上下文的参考案例。
11. 阿里中台《DDD 实践白皮书 2020》 —— 阿里电商、供应链场景的 DDD 实战案例。
12. 腾讯《微服务与 DDD 实践 2021》 —— 微信支付、腾讯视频场景的 Context Map 设计。
13. Microsoft 《Domain-Driven Design for Microservices》,Azure Architecture Center —— GDPR/PCI-DSS 合规场景的限界上下文参考。
14. Team Topologies(by Matthew Skelton & Manuel Pais),2019 —— 团队结构与限界上下文的对齐方法。

自检报告

关键术语命中次数 (grep -c)

结构核对

• §1 为什么这个专题重要 ✓
• §2 DDD 战略设计全景(含 4 大概念对比表) ✓
• §3 子域划分详解(含电商 9 行案例 + 打分工具) ✓
• §4 限界上下文详解(含 4 信号 + 3 上下文 dataclass) ✓
• §5 上下文映射 9 大模式(含对比表 + ACL 翻译层) ✓
• §6 通用语言详解(含 Event Storming + 20 词术语表) ✓
• §7 实战案例 4 个 ✓
• §8 选型决策树 + 9 维度对比表 ✓
• §9 踩坑 6 个(症状+原因+修法+代码四要素齐全) ✓
• §10 速查表/口诀/Checklist ✓
• §11 调研依据 14 处 ✓