【软件架构设计方法论（7）】领域建模1：什么是领域模型？

核心观点：领域模型就像业务世界的"地图"，它用可视化的方式把业务概念和它们之间的关系画出来，让开发者和业务人员能够用同一套"语言"沟通，避免"鸡同鸭讲"的尴尬。

什么是领域模型？这是很多开发者在接触领域驱动设计时遇到的第一个问题。业务人员说的"账户"、“凭证”、"挂失"到底是什么意思？它们之间有什么关系？为什么同样的需求，不同的人理解不一样？这些问题背后，其实都指向一个核心问题——如何让团队对业务领域达成一致的理解？

一、领域模型是什么？

领域模型就是把业务世界的概念和关系，用图形化的方式画出来。

就像盖房子前要先画建筑图纸一样，做软件前也要先画"业务图纸"。这个"业务图纸"就是领域模型。它不仅仅是罗列业务词汇（比如"账户"、“凭证”），更重要的是展示这些概念之间的关系。

例如，在银行系统中，一个"账户"可能对应多个"凭证"（银行卡、存折、存单），而每个"凭证"都有生效日期和作废日期。这些关系如果用文字描述，可能需要好几段话，但用领域模型画出来，一眼就能看懂。

具体来说，类图会这样展示：账户和凭证是一对多的关系（一个账户可以有多个凭证），而凭证又有三种类型——银行卡、存折、存单，它们都继承自"凭证"这个父类。银行卡有卡号，存折有存折号，存单有存单号，虽然都是凭证号，但格式不同。这些关系，用类图一画，关系就清楚了。

更重要的是，领域模型通常用两种图来表示：类图（展示概念之间的关系）和状态图（展示业务对象的状态变化）。就像地图有地形图和交通图一样，类图告诉我们"有什么"，状态图告诉我们"怎么变"。

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

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

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

解决沟通不足的问题

很多项目失败，不是因为技术不行，而是因为开发者和业务人员"说不到一块去"。业务人员用业务术语（比如"挂失"、“解挂”），开发者用技术术语（比如"状态机"、“事务”），双方都觉得对方说得对，但理解却不一样。

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

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

解决分析瘫痪的问题

有些项目一分析需求就停不下来，讨论来讨论去，就是定不下来。比如银行系统中，客户、账户、凭证之间的关系到底怎么理解？“一卡通”、"一折通"这些概念反复讨论，就是理不清楚。

领域模型提供了一个渐进式的方法：理解一点，画一点，公开讨论，再理解一点，再画一点。就像盖房子，不是一次性把所有图纸都画完，而是先画地基，再画框架，再画细节。每画一层，团队的理解就深入一层，讨论就聚焦一层。

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

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

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

提供稳定的设计基础

技术会变（从命令行界面到Web界面），数据存储会变（从文件到数据库），但业务的核心概念往往很稳定。比如航空订票系统，无论界面怎么变，系统怎么升级，“航班”、“乘客”、"折扣策略"这些核心概念不会变。

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

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

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

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

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

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

总结：领域模型是团队沟通和系统设计的共同语言

领域模型的价值不在于画得有多漂亮，而在于它让团队对业务有了共同的理解。就像地图的价值不在于画得有多精确，而在于它让所有人都知道"我们在哪里，要去哪里"。

因此，做项目时，不要急于写代码，先花时间把领域模型画出来。这个过程可能会发现很多之前没想清楚的问题，可能会推翻之前的假设，但这些都是值得的。因为在纸上修改模型，比在代码里修改系统要容易得多，成本也低得多。

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

 

参考：
《软件架构设计》—温昱