架构上如何设计领域模型和数据模型？

小伙伴们对数据库编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《架构上如何设计领域模型和数据模型？》，就很适合你，本篇文章讲解的知识点主要包括MySQL、Java、ddd。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

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

扪心自问，你有多久没有画数据模型和领域模型了？

现在回想起来，我当时的纠结源自于我对领域模型和数据模型这两个重要概念的不清楚，先前看过DDD(领域驱动设计)，里面一句话我觉得讲的很不错，一个类型可以充当多个角色，这个角色可以是显式的(实现了某个接口或基类)，也可以是隐式的(承担的具体职责和上下文决定)。

但是每次在新的需求下来，出设计方案的时候在数据模型和领域模型上会耽误一些时间，根本原因在于对这两个概念混淆。也因为如此，在设计方案或者在开发过程中会频繁修改数据模型的设计，因为如果底层的逻辑、概念、理论基础没搞清楚的话，其构建在其上的系统也会出现问题，非常严重的问题。

借鉴DDD(领域驱动设计)的一些设计原则，我觉得有必要花时间认真明晰这两个概念，帮助大家在工作中，更好的做设计决策。

一 概念定义

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

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

一个强调的是实体，另一个强调的是关系，再细想下我们当初建模的时候都是用啥的啥图-ER图，这下子就被慢慢带偏了。设计的数据模型里面带了实体声明也带了业务关系，两者开始混淆。

是的，二者的确有一些共同点，有时候领域模型和数据模型会长的很像，甚至会趋同，这很正常。但更多的时候，二者是有区别的。正确的做法应该是有意识地把这两个模型区别开来，分别设计，因为他们建模的目标会有所不同。

如下图所示，数据模型负责的是数据存储面向DB，其要义是扩展性、灵活性、性能。而领域模型负责业务逻辑的实现，其要义是业务语义显性化的表达，以及充分利用OO的特性增加代码的业务表征能力。

途中标识灰色的部分其实还可以细分，业务到模型之间也可进行拆分，涉及到一些命名，这里就不做展开。感兴趣的可以查阅:PO、VO、DAO、BO、DTO、POJO能分清吗？

在日常开发过程中，我们在很多的系统业务设计上，并没很好的处理数据模型和领域模型的关系，反而在设计的时候一个是把数据模型当领域模型，另一个是把领域模型当数据模型。

二 错把领域模型当数据模型

最近在优化低代码那块的元数据优化，里面涉及到一些元数据存储、拓展问题。这块逻辑大致可以简单概括:
数据表单设计时候，用户可以动态配置列的属性以及对列属性根据对应的数据类型动态匹配相应函数。

对于这个规则，领域模型很简单，就是提供了列基本配置信息和属性配置信息配置数据，如下图所示：

如果按照这个思路下去就会存在两张表meta_field_definition、meta_field_attribute 两张数据表，一张用来存储列的基础定义，另一张用来定义列的属性配置以及拓展。

如果我们这个干了，我们就犯了把领域模型当数据模型的错误，这里设计一张数据表足够。在原来的元数据列定义表里面加属性配置字段fd_attribute 以Json的形式存储，再基础表单的基础上加拓展表fd_extend_feature（当前业务用不上作为基础保留的拓展字段）

调整后有什么好处：
首先，一张表单的维护成本肯定比多张表的维护成本低
其次，其数据的扩展性更好。比如：针对某种数据类型要支持某种定制的业务配置和函数支持，如果是一张表，我们就需要往属性表里面继续添加新的业务支持配置。但是如果我们修改为一张表在原有的元数据中保持不变在属性拓展里面以JSON格式添加配置即可。

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

三 错把数据模型当领域模型

的确，数据模型最好尽量可扩展，毕竟，改动数据库可是个大工程，不管是加字段、减字段，还是加表、删表，都涉及到不少的工作量。
拿上面的案例来讲

可以注意到fd_extend_feature 拓展表所创建的，便于对表的垂直拓展补充。JSON字段也好，垂直表也好，虽然可以很好的解决数据存储扩展的问题，但是，我们最好不要把这些扩展（features）当成领域对象来处理，否则，你的代码根本就不是在面向对象编程，而是在面向扩展字段（features）编程，从而犯了把数据模型当领域模型的错误。更好的做法，应该是把数据对象（Data Object）转换成领域对象来处理。但是在处理改字段的时候，如果频繁操作addFdExtendFeature、getFdExtendFeature是一种典型的把数据模型当领域模型的错误示范。

四 总结

在日常设计和开发中我们应该是把领域模型、数据模型区别开来，让他们各司其职，从而更合理的架构我们的应用系统。其中，领域模型是面向领域对象的，要尽量具体，尽量语义明确，显性化的表达业务语义是其首要任务，扩展性是其次。而数据模型是面向数据存储的，要尽量可扩展。

回归到主题一个类型可以充当多个角色，这个角色可以是显式的（实现了某个接口或基类），也可以是隐式的（承担的具体职责和上下文决定），

• 数据模型：面向持久化，数据的载体。
• 领域模型：面向业务，行为的载体。

【原文地址】：原文跳转
【欢迎关注】：码农架构

专注于系统架构、高可用、高性能、高并发类技术分享

本篇关于《架构上如何设计领域模型和数据模型？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！