1.3 什么项目该用 DDD：适用性评估
1.3 什么项目该用 DDD：适用性评估
本节摘要：DDD 不是普适药，它的成本结构决定了只有特定形态的项目能回本。本节给出一套五维评估清单——领域复杂度、规则变更频率、系统生命周期、团队协作结构、领域专家可得性——并演示青柚商城如何用它说服了自己，又如何用它劝退了内部工具团队。
先泼一盆冷水
青柚商城的技术负责人复盘会后干的第一件事不是立项 DDD，而是把两个团队拉来各做了一次评估：电商交易域做完了，内部行政系统团队被他劝回去了。这个顺序值得每个团队模仿——先判断该不该用，再研究怎么用。
为什么需要评估？因为 DDD 的成本是前置的、确定的：领域专家工时、建模会议、代码重组纪律，每一项都在第一周就开始花钱。而收益是后置的、 contingent 的：只有当业务复杂度和变更频率足够高时，"规则有唯一权威归属"的复利才能盖过前置成本。前置成本固定、后置收益依赖条件——这种成本结构天然需要一道准入判断。
五维评估清单
逐条对照打分，每项按 1 到 5 打分，总分与单项下限一起看：
| 评估维度 | 关键问题 | 低分信号（1-2 分） | 高分信号（4-5 分） |
|---|---|---|---|
| 领域复杂度 | 规则数量与规则间交互是否超过单人脑容量 | 增删改查为主，规则一目了然 | 规则相互纠缠，新需求常牵出意想不到的连锁 |
| 变更频率 | 核心规则多久变一次 | 半年以上一次 | 每个迭代都在调整策略类规则 |
| 生命周期 | 系统预计服役多久 | 一年内会被替换 | 长期服役，持续加需求 |
| 协作结构 | 业务与技术是否长期耦合协作 | 一次性交付，验收即结束 | 常驻业务团队，需求持续涌入 |
| 专家可得性 | 能否稳定获得领域专家的参与时间 | 专家不可得或太忙 | 专家能每周固定投入 |
使用规则有三条。第一条：总分 18 分以上才值得立项。第二条：单项否决——"专家可得性"低于 2 分直接不通过，因为 DDD 的通用语言必须有活人来源，靠文档考古建不起语言。第三条：允许部分采用——复杂域用 DDD，简单域保持原样，不必整站推开。
青柚商城的两张评估表
交易域（通过）：领域复杂度 5 分——叠加、互斥、分摊规则在四个系统各有一份副本；变更频率 5 分——营销策略几乎每迭代调整；生命周期 4 分——主系统持续服役；协作结构 5 分——运营、产品、技术常驻协作；专家可得性 4 分——运营主管每周能给出固定会议时间。总分 23，立项。
行政系统（劝退）：复杂度 2 分——审批流清晰；变更频率 2 分——半年不动一次；生命周期 3 分；协作结构 2 分——外包交付；专家可得性 3 分。总分 12，且复杂度不达下限。结论：继续用原来的表单工作流方案，省下的成本投给交易域。这次劝退反而给 DDD 立项加了分——团队看到推动者是拿尺子量事，而不是追风口。
常见的误判姿势
评估实践中反复出现三种误判，值得点名。误判一：拿技术兴趣当业务理由。"团队想学 DDD"不是评估项，清单里没有任何一栏叫团队意愿——想学可以拿业余项目练手，不该拿核心业务练。误判二：把代码乱当成领域复杂。有些系统规则其实简单，只是历史代码脏；这种项目需要的是重构或重写，不是 DDD——给简单领域套上聚合和上下文，只会多出一层没有意义的车间主任。误判三：低估协作复杂性。有的团队看自己"就三五个人"便打了低分，忽略了这三个人的代码同时被四个外部系统依赖、每个依赖方都有自己的口径——协作半径比团队人数更能预示收益。
还有一种反向误判同样致命：在该用的地方以"现在还不复杂"为由推迟。复杂性是长出来的，评估应该按"十二个月后的形态"打分，而不是按今天。青柚商城 1.0 的交易系统放在两年前打分也不过 14 分，但按增长曲线外推是 20 分，事后看当时立项是正确的提前量。
把评估表跑一遍：一次完整的打分演示
清单容易看懂，难的是打分时的尺度。补一次完整演示——用青柚的"积分域"当第三张表，它当年是最纠结的一个。
打分过程逐维走。复杂度：积分规则本身中等，但积分与等级、与券的兑换关系盘根错节，且兑换比率的调整牵动财务口径——3 分起步，考虑到"规则交互超过单人脑容量"的信号已出现，记 3.5。变更频率：运营每季度调整一次获取与消耗策略，大促前必有临时规则——3 分。生命周期：积分系统随主站长期服役——4 分。协作结构：运营、客服、财务三方都要碰积分口径——4 分。专家可得性：积分规则的解释权在运营，但具体到"过期清零的时点"这种细节，运营自己也说不清，要翻历史公告——2.5 分。合计 17 分，卡在立项线下方 1 分。
这张表的正确用法不是宣布"积分域出局"，而是暴露短板：唯一拖后腿的是专家可得性。处置办法是补齐语言来源——指定运营部一名资深同事做积分域的规则责任人，两周后补评，专家可得性升到 4 分，总分 18.5，进入候补队列，排在下一年度。评估的产出常常不是"是与否"，而是"差什么"——把清单当体检表用，每个低分项都对应一笔可以补的投资。
三个常被追问的问题
问：微服务化的项目是不是默认该用 DDD？ 答：默认该用战略设计那一半。服务边界的划分离不开限界上下文的语言，这部分跳不过；战术模式那一半（聚合、值对象）才视域复杂度取舍。把"要拆服务"当成全套 DDD 立项理由的，通常会在战术层生搬硬套。
问：旧系统改造，评估按现状还是按重构后打分？ 答：按"改造完成后的形态"打分。评估要回答的是"DDD 投入在目标形态下能不能回本"——存量代码的脏乱不是 DDD 要解决的问题，重构才是。两条线索：评估表回答要不要，重构计划回答怎么过渡。
问：公司里已经有团队在用 DDD 了，别的团队还需要评估吗？ 答：需要，而且这份评估更好做——有现成参照系时，把"邻团队的域"当基准样本对照打分，分歧会比凭空打分少一半。但有两件事不能省：专家可得性必须按自己的资源重新打，业务疼痛必须有自己的事故清单——借得来尺子，借不来疼痛。
三个可迁移的判断习惯
- 按十二个月后的形态打分：复杂性是变量，用增长曲线外推，别被今天的简单骗了。
- 专家可得性一票否决：没有活的语言来源，通用语言建不起来，后面全部免谈。
- 允许部分采用：一个公司、一条业务线甚至一个系统内部，都可以复杂域用 DDD、简单域不用——工具的适用边界本来就是锯齿状的。