DDD入门

说明

最近开了一个DDD项目，对DDD进行了了解和学习，所以想要开个专题，记录一下整个项目的落地过程。本篇先分享一下自己对DDD概念的理解，希望对大家有所帮助。

简介

DDD（Domain-Driven Design，领域驱动设计），是一种软件开发设计思想，其旨在以领域为核心，让软件系统在实现时能准确地围绕真实业务过程建模，专注于业务问题域。

DDD是专门解决复杂性的方法论，所以并不是所有项目都应该使用，要根据各自的业务场景进行选择。理论上讲，业务场景越复杂，DDD的应用价值越大。

DDD从简单来讲，其实只是一种“分包策略”，通过“领域划分，限界上下文，分而治之”等方法，使糅合在一起的杂乱代码显得更加井井有条，大大降低项目后期的维护与扩展成本。

专有名词解释

领域（Domain）

领域即软件要解决的问题区域。它可以细分为三个部分：①核心域（Core Domain）：组织中最重要的领域，要对它进行战略投资，并需要投入大量资源去精心打磨；②支撑域（Supporting Domain）：既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又是必需的支撑域。支撑域具有企业特性，但不具通用性；③通用域（Generic Domain）：同时被多个子域使用的通用功能子域是通用域。比如公共组件，这类应用很容易获得到，没有企业特点限制，无需太多定制化，具有通用性。

限界上下文（Bounded Context）

限界就是领域的边界，而上下文则是语义环境。限界上下文用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。

通用语言（Ubiquitous language）

通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都要使用统一的语言进行交流。

实体（ Entity ）

拥有唯一标识符，并且它们的标识符在历经各种状态变更后仍能保持一致，对这些对象而言，重要的不是属性，而是其延续性和标识，这种对象的延续性和标识会跨越甚至超出软件的生命周期，这样的对象就是实体对象。

值对象（Value Object）

值对象往往可能是多个属性的聚合，本身无唯一标识，多个属性最终形成的一个结果值，而这个结果值往往又依附在一个实际的实体Entity上面。对于值对象而言，我们只关心它们是什么，不关心它是谁。

聚合根（Aggregate Root）

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

领域服务（Domain Service）

领域服务是用来协调领域对象完成某个操作，用来处理业务逻辑的，它本身是一个行为，所以是无状态的。状态由领域对象（具有状态和行为）保存。
当需要处理多个领域对象时，需要业务逻辑写在领域服务中。

领域事件（Domain Events）

领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。

架构

DDD的架构模型因为角度不同，网上有很多，这里只选了人认为比较简单和经典的一种（cola）进行介绍。

1）适配层（Adapter Layer）：负责对前端展示（web，wireless，wap）的路由和适配，对于传统B/S系统而言，adapter就相当于MVC中的controller；

2）应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；

3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；

4）基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。

开发设计过程

个人理解

1. DDD针对的是复杂业务场景，并不一定都适合，要根据实际情况决定是否使用，因为它相较传统三层架构的学习成本高很多。
2. DDD是一种思想和方法论，没有统一的标准，可以根据项目实际情况进行调整。
3. DDD需要我们转变开发思维，由“面向过程/数据库编程”真正转变为“面向对象编程”(领域对象)，更贴合现实和业务；
4. DDD主要进行了职责的划分，明确了各领域对象的真实“领域”范围，跨域交互通过领域事件（尽量使用中间件），方便后期业务庞大起来后的拆分扩展。
5. 领域层是整个项目的核心，处理项目的业务场景。它不依赖任何模块，通过依赖倒置解除了对infrastructure层的依赖。
6. 领域对象的能力是指刨除具体业务场景，对象本身具备的能力。如“人的性别只能是非男即女”这种校验，“狗会叫”这种能力；
7. 领域层与infrastructure层交互通过接口进行，领域层只关心业务，具体的技术实现由infrastructure层决定，这样屏蔽了后期维护更换实现技术对领域层的影响。例如消息队列技术变更、数据库技术变更等。
8. 总之，DDD是对传统代码进行了规整分类，将项目的关注点由传统的dao换到了业务，更贴合“真实”；它从业务场景中细化出一个个的领域，细化的越明确，越合理，后期的维护、拆分、扩展等的成本就越低；它将具体的技术实现排除在了“核心”之外，这样屏蔽了技术切换对核心业务逻辑的影响，而我们真实开发中，随规模扩大，技术切换往往是很正常的事情，所以也会大大节约项目的维护成本，提高效率。

学习资料

https://www.infoq.cn/article/alibaba-freshhema-ddd-practice
https://blog.csdn.net/significantfrank/article/details/79614915
https://www.cnblogs.com/davenkin/p/ddd-coding-practices.html
https://www.toutiao.com/i6994703840402539020/?wid=1628746101967
cola框架相关可以阅读该文章：
https://www.cnblogs.com/makai/p/14240924.html
这篇文章中的领域事件部分值的阅读学习：
https://blog.csdn.net/qq_28635931/article/details/123041065