DDD领域驱动设计模型的理解和学习——一种很厉害的架构思想

一、什么是DDD

领域驱动设计，是一种架构思想。以领域模型为核心，强调在代码中体现领域的思想，开发人员和领域专家一起进行系统建设。没有一种稳定的技术框架，DDD要求领域跟技术、存储、通信无关。
解决系统老化，防止系统老化。

大泥团：不利于微服务的拆分。大泥团结构拆分出来的微服务依然是泥团机构，当服务业务逐渐复杂，这个泥团又会膨胩成
为大泥团。

面向业务来建立领域模型，比如商品领域、物流领域。
MVC架构-》领域优先的四层架构：

二、系统老化的原因

1.需求难，越来越难实现，系统越来越复杂，需求也很难提。
2.开发难，一个类上千行代码，这段代码有什么功能？能不能去掉？越来越难开发。
3.测试难，没办法单元测试，一个小需求需要回归测试，工作量变大。
4.创新难，新技术越来越多，老系统重构要花的时间越来越多，越拖越烂。

三、高质量代码的标准

高内聚、低耦合，考虑代码的可维护性、可测试性、可扩展性。
单一职责原则：每个功能模块只做单一的事情。
开放封闭原则：对扩展开放，对修改封闭。
依赖反转原则：依赖接口，而不依赖实现类。

四、DDD基础概念

4.1实体、值对象

实体承载业务：实体类里面放业务相关的属性和业务方法，每个实体的业务要求清晰。
业务是造成实体状态变化的动作，比如：转账，造成了账号（实体）的金额（实体的属性、状态）发生变化。
特别的，业务是不包含在数据库的查询，增删，保存。数据库的增删改查不影响实体状态的变化。

值对象：
order->orderItem->Address
整体和部分的关系，就是实体和值对象的关系。如果订单不存在了，订单表和地址就没有意义了。

好处：入口单一，当访问值对象的业务时，要从实体访问。

4.2贫血模型

实体+业务方法=充血模型
POJO=贫血模型
贫血模式就是类里面只有成员变量和get、set方法。
贫血模型的问题：不知道这个POJO对象实体以前的业务有哪些逻辑（贫血失忆症）

4.3仓库和工厂

仓库repository：放着一个对象池，放着我们业务需要的所有对象和数据。
工厂factory：组装复杂对象，组装从数据库拿的数据。

4.4防腐层

防腐层ACL：隔离第三方的依赖，防止第三方业务的变化影响自己的业务。
对第三方接口的返回值进行一个结果集的封装。

4.5基础设计层

系统内调用的基础组件比如mq，可以将方法脱构，类脱构。

4.6领域服务

每个实体只能操作自己的属性，而跨实体的操作，需要抽象成领域服务，专属于当前领域使用的服务。只能调用领域的业务方法，比如转账业务。

4.7聚合

当有多个领域相同，领域与领域之间进行交互会形成一个一个聚合。在每个聚合里面会形成一个固定的聚合根。比如一个领域两个是实体，在两个实体里面聚合会指定一个聚合根，对聚合内对象的访问必须经由聚合根对象。

五、DDD优点

1、需求更容易梳理：业务逻辑清晰纯净， 没有业务与实现细节之 间的复杂转换。
2、业务更容易开发：各领域内完全自治， 不用担心其他模块的影响。
下单模块的Account与账务管理模块的Account属性与方法都可以完全不同，没有任何直接关联。
3、更容易单元测试：业务与外部依赖完全隔离，各功能组件的依赖也都是独立的。
很容易设计单元测试案例，单独测试。
4、技术容易更新：所以实现细节都是业务逻辑的扩展，指哪改哪。对业务无影响。

六、DDD四层架构规范

1、领域中的对象由实体和值对象组成。对值对象的访问必须经由所属的实体对象。
2、相关联的一组实体与值对象组成聚合。对聚合内对象的访问必须经由聚合根对象。
3、跨实体的操作必须经由领域服务。
4、应用服务层只通过领域服务或者聚合根来组织业务，自身不带任务实现逻辑。
5、业务与数据隔离。领域层只关注业务，数据支撑全部交由基础设施层。