竟然今日才入选ACM Fellow，他们可是程序员的“祖师爷”

这样做的好处很明显：

• 首先，维护一张数据库表肯定比两张的成本要小。
• 其次，其数据的扩展性更好。比如，新需求来了，需要增加一个建议价格(suggest price)区间，如果是两张表的话，我需要在price_range中加两个新字段，而如果是json存储的话，数据模型可以保持不变。

可是，在业务代码里面，如果是基于json在做事情可不那么美好。我们需要把json的数据对象，转换成有业务语义的领域对象，这样，我们既可以享受数据模型扩展性带来的便捷性，又不失领域模型对业务语义显性化带来的代码可读性。
 

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

错把领域模型当数据模型

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

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

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

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

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

领域模型和数据模型的概念定义

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

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

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

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

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

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!