什么是领域模型？

核心观点： 领域模型如同业务世界的“地图”，它以可视化的方式描绘了业务概念及其相互关系，使开发者和业务人员能够使用同一套“语言”进行交流，避免沟通时的误解。

什么是领域模型？这是许多开发者在接触领域驱动设计时常遇到的第一个疑问。业务人员提到的“账户”、“凭证”、“挂失”具体指什么？这些概念之间有何关联？为什么相同的需求不同的人会有不同的理解？这些问题背后，实际上都指向一个关键问题——

如何确保团队对业务领域有统一的理解？

一、领域模型是什么？

领域模型是将业务世界的概念和关系以图形化形式展示出来。

就像建造房屋前需要先绘制建筑图纸一样，在开发软件之前也需要先绘制“业务图纸”。这份“业务图纸”即为领域模型。它不仅列举了业务术语（如“账户”、“凭证”），更重要的是展示了这些概念之间的关联。

例如，在银行系统中，一个“账户”可能对应多个“凭证”（银行卡、存折、存单），每个“凭证”都有生效和失效日期。这些关系如果用文字描述，可能需要多段话才能说明白，但通过领域模型图示化后，一目了然。

具体来说，类图会这样展示：账户与凭证之间是一对多的关系（一个账户可以关联多个凭证），而凭证有三种类型——银行卡、存折、存单，它们都继承自“凭证”这一父类。银行卡有卡号，存折有存折号，存单有存单号，虽然都是凭证号，但格式各异。这些关系通过类图一画，就变得清晰明了。

更重要的是，领域模型通常使用两种图表来表示：

• 类图（展示概念之间的关系）和
• 状态图（展示业务对象的状态变化）。

就像地图有地形图和交通图一样，类图告诉我们“有什么”，状态图则告诉我们“如何变”。

例如，储蓄账户的状态图会展示：账户有四种状态——正常、挂失、冻结、销户。从“正常”状态可以转到“挂失”状态（需要身份验证），也可以转到“冻结”状态（需要授权），还可以转到“销户”状态。从“挂失”状态可以回到“正常”状态（需要解除挂失），从“冻结”状态可以回到“正常”状态（需要授权解除）。在“正常”状态下，可以进行存款和取款交易。这些状态转换规则通过状态图一画，业务流程就清晰明了。

二、为什么需要领域模型？

领域模型是连接业务与技术的桥梁，它解决了三个核心问题：沟通不足、分析瘫痪和理解偏差。

解决沟通不足的问题

很多项目失败并非因为技术问题，而是因为开发者和业务人员“说不到一块去”。业务人员使用业务术语（如“挂失”、“解除挂失”），而开发者则使用技术术语（如“状态机”、“事务”）。双方都觉得对方说得对，但理解却各不相同。

领域模型就像为双方提供了一本“翻译词典”。当开发者问“挂失是什么意思”时，业务人员可以指着状态图说：“看，这就是挂失——账户从‘正常’状态变为‘挂失’状态，需要身份验证。挂失后账户不能进行交易，但可以通过解除挂失回到正常状态。” 当业务人员问“这个功能如何实现”时，开发者可以指着类图说：“看，账户与凭证是一对多的关系，凭证有三种类型（银行卡、存折、存单），因此我们可以设计一个Account表和一个Credential表，Credential表通过外键关联Account表，并使用type字段区分凭证类型。”

更重要的是，领域模型不是开发者单独绘制的，而是与业务人员共同完成的。在绘图过程中，双方会不断讨论、澄清和确认，这个过程本身就是深度沟通。就像两个人一起看地图找路，比一个人看地图、另一个人听描述要准确得多。

解决分析瘫痪的问题

有些项目在需求分析阶段迟迟无法推进，讨论来讨论去，就是定不下来。例如，在银行系统中，客户、账户和凭证之间的关系到底如何理解？“一卡通”、“一折通”这些概念反复讨论，却始终理不清楚。

领域模型提供了一种渐进的方法：

理解一点，画一点，公开讨论，再理解一点，再画一点。就像建造房屋一样，不是一次性完成所有图纸，而是先绘制地基，再绘制框架，最后绘制细节。每绘制一层，团队的理解就加深一层，讨论也更加聚焦。

例如，在软件配置管理系统的开发中，最初的理解可能是零散的：有“角色”、“工件”、“变更”、“基线”等概念，但关系不明确。通过不断建模，逐渐发现：

• 角色执行活动，活动可以生成、使用或修改工件
• 工件产生变更，但不是所有变更都需要管理，只有受控的变更才能纳入基线
• 配置项是工件的子类，只有通过评审的工件才能成为配置项
• 基线由多个配置项组成，是在某个时间点的快照

这些关系链最终形成一个完整的领域模型。这个过程就像拼图，一块块地拼凑，最终拼出完整画面。

提供稳定的设计基础

技术会变化（从命令行界面到Web界面），数据存储也会变化（从文件到数据库），但业务的核心概念通常非常稳定。例如，在航空订票系统中，无论界面如何变化，系统如何升级，“航班”、“乘客”和“折扣策略”等核心概念不会改变。

领域模型抓住的就是这些稳定的中心概念。因此，一个良好的领域模型可以跨越技术变迁，成为系统设计的稳定基础。就像房子的结构图一样，无论装修风格如何变化，承重墙的位置不变。

三、领域模型在软件开发中的作用

领域模型贯穿于软件开发的各个阶段，从需求分析到架构设计，再到编码实现，它都是关键的思考工具。

在需求分析阶段，领域模型帮助团队理解业务，构建共享的词汇表。在架构设计阶段，领域模型影响系统的可扩展性——优秀的领域模型使系统易于扩展，而较差的领域模型则导致系统难以扩展。在编码实现阶段，领域模型成为业务层的核心，指导代码的组织方式。

更重要的是，领域模型还对界面设计和数据设计产生影响。界面展示的内容很大程度上取决于领域模型中的重要概念。数据存储的内容由领域模型中的关系直接决定数据库表的设计。

这意味着，领域模型不是可有可无的装饰品，而是软件系统的“基因”。系统的功能范围、扩展能力和用户体验都受到领域模型的重要影响。

总结：领域模型是团队沟通和系统设计的共同语言。领域模型的价值不在于绘制得多么精美，而在于它使团队对业务有了共同的理解。就像地图的价值不在于绘制得多么精确，而在于让所有人都明白“我们在哪里，要去哪里”。

因此，在项目中，不要急于编写代码，先花时间构建领域模型。这一过程可能会发现许多之前未考虑清楚的问题，甚至推翻之前的假设，但这些都是值得的。因为在纸上修改模型比在代码中修改系统要容易得多，成本也低得多。

更重要的是，领域模型不是一次性的工作，而是一个随着对业务理解加深不断迭代的过程。就像地图需要定期更新一样，领域模型也需要根据新的业务需求进行调整。但核心概念和关系往往会在迭代过程中越来越清晰，越来越稳定。