DDD领域模型有必要么？

领域模型的基本概念

文章抽出来的知识点是个人差不多整理的，有更好的请告知，轻喷。

我们先来看看一篇我关注博主的DDD入门文章从零开始的领域驱动设计

美团技术文章参考  领域驱动设计在互联网业务开发中的实践 - 美团技术团队

entity和value object     实体和值对象

一定的数据冗余，有助于查询速度，以及相关数据的维护

微服务领域需要value object的数据冗余，因为数据库相互隔离

认识到在不同场景下，不同的关注点 实体的界限/边界问题

模式

贫血模型 类似mybatis

充血模型 类似JPA的使用

失血模型、涨血模型 略

聚合和聚合根 --- 根(root)和边界(boundary)

类似同一个项目下不同业务团队，很多事情是有边界；理清楚这个边界，对设计、调用和管理等等都友好

类似接口的设计，不是为了业务需求去设计接口，而是有组合和边界以及入口的概念。

依赖业务上下文，其实是一个整理和规划的过程，让职责清晰

模式 ---包结构

按照业务来划分包结构，还是按照功能来划分包结构

一般的项目按照功能 controller、service来划分包结构

大型或者将要拆分的微服务可以按照业务来划分包名

DDD的作用

决定微服务的不是框架的选择，不仅仅是 restful 或者 rpc 的接口设计风格的抉择，而更应该关注拆解，领域，限界上下文，聚合根等等一系列事物，这便是我所理解的领域驱动设计对微服务架构的指导意义。

 

DDD解决了什么问题

我又从网上找了一篇博客  DDD是个啥？它解决了什么问题？

1、业务人员跟技术人员沟通的问题。 2、代码质量问题

理论上，严格以DDD方式实现的代码就能做到。DDD就是要解决上述的“代码质量”的问题。

前提是所有参与编码的人，不管是老人还是新人，都熟知DDD的编码规则/习惯。

DDD的战略工具

领导们用的，就是划分领域，子领域，构建限界上下文映射图。

DDD的战术工具

这是团队开发人员需要关注的，具体的有：

聚合、实体、值对象、领域服务、领域事件。

这些名词不是什么高大上的东西，它们只是工具。我们要想把活儿干好，首先要了解有哪些可用的工具，哪些场合应该用哪种工具。

只有熟悉了这些工具的用途和使用场景，我们才能码出“高质量”的代码。

我们再次参考一篇新的博客解构领域驱动设计（一）：为什么DDD能够解决软件复杂性，作者从实践的角度再次说明了DDD的用处

反思了技术开发过程中碰到的问题

1、需求评审、设计评审、代码评审 非常痛苦

2、做大型开发时候、从产品到技术理解和对齐不一致

尝试使用代码规范和质量管理的方式来解决问题、发现未能解决问题。

觉得DDD可以解决以上问题：

DDD解决软件复杂性的方法核心为两点：

通过领域模型为业务知识建模，领域模型作为业务、技术团队沟通的统一语言。

确保软件实现与领域模型保持一致。

软件实现与领域模型保持一致是本书的核心思想，DDD构建了一套完整的方法论来支持领域模型驱动程序设计。这套方法论简述如下。

分层架构：业务规则的代码只占软件很少的代码却是最核心的部分代码，将其分离出来作为独立的领域层，使领域层的实现与领域模型保持一致，领域层的业务对象不再是贫血模型。

领域驱动设计：领域驱动设计，即领域模型驱动程序设计。这里给出了如何通过代码表达领域模型的编码模式。这些模式包括：关联、实体、值对象、服务、聚合根、Repository、Factory。它们构建了将领域模型表达成代码的方法论，保证了代码和设计一致。

战略设计：复杂领域模型的实现方法论。

个人观点

以上的观点，其实从理论上来说一个好的办法，从实践上来说也是有一定作用的；

但是如果要用好DDD，需要参与的人理解并使用DDD，这是极为困难的；

有一段时间我很少编程：

一方面作为需求中间人的角色像所有的开发人员输出需求保证需求的统一、

 另外一方面作为对整体需求最了解的人之一、从整体上去设计功能的落脚点，整体设计需不需要调整等等、

最后是花了大量的时间，强制去推动代码规范和代码质量。当然花了时间，收获还不错（主要是因为业务相对简单）

所以DDD解决的问题我觉得代码规范和代码质量也能解决，关键是所有的参与者去理解、并且被推动去强制执行。

而DDD是一个新的东西，而且相对晦涩，我对它的效果是持否定的。

如果有人成功，我觉得可能是业务相对简单，整体的人员也是相对牛逼，都是高P。

很高兴看到文章解构领域驱动设计（一）：为什么DDD能够解决软件复杂性的评论观点和我类似

后续

本质上代码规范、代码质量和领域驱动模型是要解决什么问题    1、相对更高的开发效率     2、系统质量更高    3、系统更容易维护和管理（需求在所有人理解都是相对一致）

是否让架构师可以指导项目。对一般项目而已怎么设计无所谓，注重的是开发效率和后期维护；对重大项目而已，业务非常复杂，架构也非一成不变，架构师跑马观花不如真实去了解业务的情况再做设计。

为什么会带来这些问题，因为产品、需求、开发、测试等等质量不一、对需求的理解不一致；

而对需求的理解不一致：个人理解主要原因是行业的细分带来的割裂感、导致信息的相对不流畅，毕竟“交流的不是一种语言”

沟通从来都是最复杂的问题（更别提的是语言不通，鹿头不对马嘴 哈哈哈），变化是最不变的道理。

如果这些复杂问题都可以解决，还需要人类编程么？

所以我更推荐是产品、需求、开发中间人这类的角色、从分层上去寻求融合，当然困难点是这个人足够可靠，我感觉现在好像很多都类似这种模式。

程序员总是把一切想的太美好，以为所有的问题都有解决方案，殊不知人才是最难搞定的。

2021.01.14 Add

DDD目标群体

晚上想了一下DDD实际用处，我以为对大型的复杂微服务的设计和微服务的拆分是比较有用的，适合架构师掌握的技术。

架构师关注技术全局和架构以后的迭代，DDD有助于更清晰更靠谱的去规划，去划分边界等等，但是要结合具体的业务去实现场景化落地，不然也是空中楼阁。

DDD对于微服务的作用类似于在微服务架构思想出现之前，微服务架构对于分布式应用的指导作用。

不过一方面面上狭窄许多，一方面没有类似Spring Cloud这种场景化落地的方式，还是太虚不好落地，而落地又得结合实际。