1.2 领域模型是核心资产：DDD 的价值主张
1.2 领域模型是核心资产：DDD 的价值主张
本节摘要：DDD 的全部主张可以压缩成一句话——领域模型是软件公司最该认真经营的资产。本节解释这句话的反直觉之处，拆解"通用语言、边界、模型"三件套如何互相咬合，并诚实地算一算把模型当资产来养的成本。
一个反直觉的主张
多数团队的资产清单上写着：代码、服务器、数据、文档。没有人把"模型"列进去，因为它通常根本不存在为一个独立的东西——它散落在代码结构、数据库表和某些人脑子里。DDD 的第一个主张就是把它请出来，给它正式的地位。
先说清楚"领域模型"指什么。它是对业务领域中被选定片段的知识组织：不只是数据结构，而是数据、行为、约束和词汇四样东西的捆扎。以青柚商城的"优惠券"为例：一张优惠券有面额和使用门槛（数据），能判断自己"对这笔订单是否可用"（行为），受"每单限用一张"的约束（规则），并且只在营销上下文里被叫做"券"、在交易上下文里被叫做"优惠明细行"（词汇）。四样俱全，才配叫模型；只把字段抄进一个类，那只是数据的搬运。
为什么说它是资产？对照资产的三条判据：
- 有明确的所有者。文档是没人认领的，模型有归属——哪个团队、哪个人对"优惠券模型"的正确性负责，是有名字的。
- 有演化节奏。资产会被持续投入和维护。优惠券模型跟着业务规则一版版演进，每轮变更都有评审，而不是画完归档。
- 有复利回报。今天把"满减与券能否叠加"这个判断写进券模型，明天所有调用方（交易、财务、客服）都自动继承正确答案，不用各自维护副本。
文档三条都不满足：没所有者、没演化、每用一次还要人工核对是否过期。这就是"模型是资产，文档只是资产的表达快照"的含义。
三件套怎么咬合
模型不会自己变准。DDD 配了两件工具守着它：通用语言和边界。
通用语言是业务专家与开发共用的词汇体系，规矩很硬：会上的词、文档里的词、代码里的类名方法名，必须是同一套。产品说"核销"，代码里就该有 redeem 这样的方法与之对应。语言失守之处，模型必然失真——第 2 章会用一整节排错实录来展示这件事怎么发生。
**边界（限界上下文）**给语言划定生效范围。"订单"这个词在交易上下文和仓储上下文里含义不同，不是缺陷而是设计：与其造一个万能的"订单"模型去兼容所有含义，不如承认语义本身就分属不同的疆域，各建各的模型，疆域之间立契约。语言、边界、模型三者的关系可以概括为：边界内锻造语言，语言凝聚成模型，模型反过来校准语言。
三件套的咬合关系，用一张图固定下来：
模型资产的三根支柱
诚实地算算成本
把模型当资产是要付费的，账要摊开算。第一笔是专家时间：建模型的每一步都需要真正懂业务的人在场上，青柚商城的做法是给运营主管每周固定留出参与建模会议的工时——这笔投入在多数团队是最大的阻力，因为它花的是"最贵的人的时间"。第二笔是重构纪律：模型演进意味着代码持续重组，"先跑起来以后再改"的欠条在 DDD 项目里利滚利极快，团队需要守住"模型变更不过夜"的纪律。第三笔是认知成本：通用语言、限界上下文这些概念本身有学习曲线，团队要一起爬。
什么时候这笔账划算？业务规则密度高、变更频繁、系统生命周期长的场景，资产的复利会远远跑赢成本；反过来，规则简单或系统活不过一年的项目，这笔投资大概率打水漂——这正是下一节适用性评估要解决的问题。
模型资产怎么在组织里活着
资产判据听着抽象，落到组织里就是三个具体的运转机制。青柚商城交易上下文的做法可以直接抄。
机制一：模型例会。每双周一次，三十分钟，议程只有一项——过一遍本周期业务规则与模型的偏差。运营主管必须到场（这是 1.3 里"专家可得性"打 4 分的兑现方式），会上产出的不是会议纪要而是模型修订项：哪个值对象缺了约束、哪条规则的归属放错了。例会死亡的方式通常是被当成汇报会——主持人要守住一条规矩：不带修订项的汇报不上桌，只听不讲的不留席。
机制二：模型与代码的对账清单。类似 1.1 词汇表的思路，给模型也建一张两栏对账表：左栏是模型里的概念与不变量，右栏是代码里对应的类与方法。季度盘点时，左栏有而右栏无的，是"纸面模型"（要么实现要么删）；右栏有而左栏无的，是"野生逻辑"（要么升格进模型，要么降格为技术细节）。这张表是"模型与代码两张皮"的检测仪——两张皮的团队做一次盘点，通常会翻出十几处野生逻辑，每一处都是未来口径事故的候选。
机制三：模型变更走轻量评审。资产要演化，但演化不能没有闸门。青柚的规矩是：模型修订项由领域责任人（不是架构师）签署，签署的依据不是权力而是可追溯——每个修订项挂着一条业务事实（哪个需求、哪次事故、哪句会上确认的原话）。这样半年后回看模型演进史，能看到的是业务变化的轨迹，而不是某个人的偏好史。
一次完整的资产化对照
用一个真实概念走一遍"数据袋到资产"的全程。青柚的"优惠券"最初在营销系统里是一张表加一个校验函数：字段是券码、面额、门槛、状态，校验函数判断"能不能用"。资产化改造后它变成了三样东西的组合：一个券值对象（面额与门槛不可变，自带门槛判断）、一个券实体（券码即身份，状态机管理待发放、已发放、已核销、已过期）、一条"每单限用一张"的聚合不变量（长在订单聚合里，3.5 讲过它的归属争议）。改造前后对照，变的不只是代码结构：改造前，"券过期了还能不能退"没人说得清，因为规则散在两个 if 里；改造后，答案就在券实体的状态机里，客服查一下就有。资产化的检验标准就一条：关于这个概念的业务问题，能不能在模型里找到唯一权威的答案。
两个常被追问的问题
问：文档和模型到底什么关系？文档要不要写？ 答：模型是本体，文档是模型在某个时刻的投影。词汇表、上下文地图这类"与代码互相锚定"的文档要写也要养；而那些只在建模会议出现的分析文档，写完就该允许它死——判据还是资产三判据：有主、在演化、被引用的文档才配投入维护工时。
问：小团队没资源开模型例会怎么办？ 答：机制可以合并但不能省。三个人的团队，把模型对账并进每次代码评审：评审时多问一句"这个改动动了哪个概念、哪个不变量"，三十秒的提问就是微缩版例会。机制的本意是让模型有人管，而不是让人有一套流程可表演。
带走这几句
- 领域模型是数据、行为、约束、词汇的捆扎，不是数据库表的类映射；只抄字段不装行为的不叫模型。
- "模型是资产"的检验标准：有所有者、有演化节奏、有复利回报——文档三条都不满足。
- 通用语言负责口径统一，限界上下文负责划定语言生效范围，模型是二者共同锻造出的本体。
- 建模的主要成本是领域专家的固定工时与持续重构的纪律，这笔投资只在复杂业务与长生命周期项目上回本。