导读：本文介绍领域模型和数据模型的概念定义，并举例说明两者相互混淆的错误用法，分享如何正确地应用它们。

作者｜张建飞

依稀记得我第一次设计一个系统的时候，画了一堆 UML（Unified Modeling Language，统一建模语言）图，面对 Class Diagram（其实就是领域模型），纠结了好久，不知道如何落地。因为，如果按照这个类图去落数据库的话，看起来很奇怪，有点繁琐。可是不按照这个类图落库的话，又不知道这个类图画了有什么用。

现在回想起来，我当时的纠结源自于我对领域模型和数据模型这两个重要概念的不清楚。最近，我发现对这两个概念的混淆不是个例，而是非常普遍的现象。其结果就是，小到会影响一些模块设计的不合理性，大到会影响像业务中台这样重大技术决策，因为如果底层的逻辑、概念、理论基础没搞清楚的话，其构建在其上的系统也会出现问题，非常严重的问题。

鉴于很少看到有人对这个话题进行比较深入的研究和探讨，我觉得有必要花时间认真明晰这两个概念，帮助大家在工作中，更好的做设计决策。

领域模型关注的是领域知识，是业务领域的核心实体，体现了问题域里面的关键概念，以及概念之间的联系。领域模型建模的关键是看模型能否显性化、清晰的表达业务语义，扩展性是其次。

数据模型关注的是数据存储，所有的业务都离不开数据，都离不开对数据的 CRUD，数据模型建模的决策因素主要是扩展性、性能等非功能属性，无需过分考虑业务语义的表征能力。

按照 Robert 在《整洁架构》里面的观点，领域模型是核心，数据模型是技术细节。然而现实情况是，二者都很重要。

这两个模型之所以容易被混淆，是因为两者都强调实体（Entity），都强调关系（Relationship），这可不，我们传统的数据库的数据模型建模就是用的 ER 图啊。

是的，二者的确有一些共同点，有时候领域模型和数据模型会长的很像，甚至会趋同，这很正常。但更多的时候，二者是有区别的。正确的做法应该是有意识地把这两个模型区别开来，分别设计，因为他们建模的目标会有所不同。如下图所示，数据模型负责的是数据存储，其要义是扩展性、灵活性、性能。而领域模型负责业务逻辑的实现，其要义是业务语义显性化的表达，以及充分利用 OO 的特性增加代码的业务表征能力。

然而，现实情况是，我们很多的业务系统设计，并没有很好的区分二者的关系。经常会犯两个错误，一个是把领域模型当数据模型，另一个是把数据模型当领域模型。

这几天我在做一个报价优化的项目，里面涉及到报价规则的问题，这块的业务逻辑大意是说，对于不同的商品（通过类目、品牌、供应商类型等维度区分），我们会给出不同的价格区间，然后来判断商家的报价是否应该被自动审核（autoApprove）通过，还是应该被自动拦截（autoBlock）。

对于这个规则，领域模型很简单，就是提供了价格管控需要的配置数据，如下图所示：

如果按照这个领域模型去设计我们的存储的话，自然是需要两张表：price_rule 和 price_range，一张用来存价格规则，一张是用来存价格区间。

如果这样去设计数据模型，我们就犯了把领域模型当数据模型的错误。这里，更合适的做法是一张表就够了，把 price_range 作为一个字段在 price_rule 中用一个字段存储，如下图所示，里面的多个价格区间信息用一个JSON字段去存取就好了。