领域、子域与限界上下文

DDD 的名词特别多：领域、子域、核心域、通用域、支撑域、限界上下文……这篇把"划边界"相关的概念一次讲清楚。

一、领域：说白了就是"范围"

领域这个词听着玄乎，其实核心就俩字：范围。

DDD 研究业务问题的套路，和自然科学研究复杂问题是一样的——大问题拆小，小问题再拆，拆到能轻松搞定为止。每个拆出来的小范围，就是一个子域。

拿生物课的例子类比：研究一棵桃树 → 拆成器官（根、茎、叶、花、果实）→ 器官拆成组织 → 组织拆成细胞。细胞有细胞壁，这就是最小研究单元的边界。

对应到业务上，比如保险领域：

保险领域
├── 承保子域
│   ├── 投保
│   ├── 保全（寿险）
│   └── 批改（财险）
├── 收付子域
├── 再保子域
└── 理赔子域
    ├── 报案
    ├── 查勘
    └── 定损

拆到"投保"这个粒度，就可以建领域模型了，模型落地就是投保微服务。行业不同，但逐级拆解、降低复杂度这个方法是通用的。

二、核心域、通用域、支撑域：钱花在刀刃上

子域按重要程度分三类：

类型	定义	例子	投入策略
核心域	决定公司核心竞争力的	电商的交易、推荐	重兵投入，必须自研
通用域	大家都要用、没啥个性化的	认证、权限	能买就买
支撑域	必需但既不核心也不通用	数据字典	低成本解决

为什么要分？因为资源永远有限。

有个很形象的类比：同样一棵桃树，公园园丁眼里"花"是核心域（观赏），果农眼里"果实"才是核心域（卖钱），果农甚至会剪掉疯长的枝叶保果子。

放到公司也一样——同是电商，淘宝（C2C）、京东（自营）、苏宁（线下转型）的商业模式不同，核心域的划分结果也完全不同。有的核心在物流，有的在供应链，有的在客服。划核心域本质上是在回答"我们公司靠什么赢"，这是业务战略问题，不是技术问题。

三、通用语言：让所有人说一样的话

进入限界上下文之前，得先说它的搭档——通用语言。

一个项目里有领域专家、产品、架构师、开发、测试，同一个业务概念每个人的叫法和理解都可能不一样，沟通全靠猜。通用语言就是团队在事件风暴中共同确认下来的统一术语，从需求讨论一直贯穿到代码：

• 名词 → 领域对象命名（商品、订单 → 实体）
• 动词 → 事件或命令（已下单、已付款 → 领域事件）

实践里有个很实用的技巧：用表格把领域对象记录下来——对象名、属性、在分层架构中的位置、对应的代码类名，一一映射。这样业务模型和代码模型保持一致，连不懂代码的业务人员都能按术语找到代码位置。

四、限界上下文：术语的"辖区"

通用语言有个问题：同一个词在不同场景下含义不同。

经典段子：妈妈说"能穿多少穿多少"——冬天和夏天，意思完全相反。语言离不开语义环境。

业务里也一样：

• 保险：同样围绕一份保障，投保阶段叫投保单，缴费后叫保单，改动后叫批单，理赔时叫赔案
• 电商：同一个东西，销售阶段叫商品，物流阶段叫货物

限界上下文 = 限界（边界）+ 上下文（语义环境），作用就是给通用语言划一个"辖区"，保证术语在辖区内没有二义性。英文 Bounded Context，其实翻译成"上下文边界"更好懂。

五、限界上下文和微服务的关系

这是本篇最关键的结论：

理论上，一个限界上下文就可以设计为一个微服务。

层级关系捋一下：

领域 → 拆成子域 → 子域内做事件风暴 → 形成若干聚合 → 聚合归入限界上下文 → 限界上下文 ≈ 微服务

几个补充说明：

• 子域可能包含多个限界上下文（比如理赔子域包含报案、查勘、定损）
• 也可能子域本身边界就和限界上下文重合（比如投保子域）
• "理论上"三个字很重要——实际拆分还要考虑技术异构、团队规模、运维能力等因素，不宜过度拆分

六、小结

• 领域/子域：把大问题逐级拆小，是"分而治之"
• 核心域/通用域/支撑域：区分轻重缓急，是"资源分配"
• 通用语言：统一术语，业务和代码说同一种话
• 限界上下文：给术语划辖区，消除二义性，同时也是微服务拆分的主要依据

一句话串起来：拆域是拆问题，限界上下文是定边界，边界即（未来的）微服务。