DDD之理论概论_充血模型,指将对象的属性信息与行为逻辑聚合到一个类中,常用的手段如在对象内提供-CSDN博客

本文链接：https://blog.csdn.net/CSDN_LiMingfly/article/details/143262220

DDD 的概念
什么是充血模型，领域内都包括什么，实体、聚合、值对象，有什么区别？这样一些"为什么"的概念，也是战术设计过程中非常重要的知识项。搞清楚它们才能做 DDD 设计。
充血模型
充血模型，指将对象的属性信息与行为逻辑聚合到一个类中，常用的手段如在对象内提供属于当前对象的信息校验、拼装缓存Key、不含服务接口调用的逻辑处理等。
在这里插入图片描述
1:这样的方式可以在使用一个对象时，就顺便拿到这个对象的提供的一系列方法信息，所有使用对象的逻辑方法，都不需要自己再次处理同类逻辑。
2:但不要只是把充血模型，仅限于一个类的设计和一个类内的方法设计。充血还可以是整个包结构，一个包下包括了用于实现此包 Service 服务所需的各类零部件（模型、仓储、工厂），也可以被看做充血模型。
3:同时我们还会再一个同类的类下，提供对应的内部类，如用户实名，包括了，通信类、实名卡、银行卡、四要素等。它们都被写进到一个用户类下的内部子类，这样在代码编写中也会清晰的看到子类的所属信息，更容易理解代码逻辑，也便于维护迭代。
领域模型
领域模型，指特定业务领域内，业务规则、策略以及业务流程的抽象和封装。在设计手段上，通过风暴模型拆分领域模块，形成界限上下文。最大的区别在于把原有的众多 Service + 数据模型的方式，拆分为独立的有边界的领域模块。每个领域内创建自身所属的；领域对象（实体、聚合、值对象）、仓储服务(DAO 操作)、工厂、端口适配器Port（调用外部接口的手段）等。

那么，现在这里有几个概念；领域服务、领域对象、仓储定义、事件消息、端口适配器。我们先来看他们是怎么从贫血模型演变过来的，在细分讲解每个概念。
在这里插入图片描述
A:在原本的 Service + 贫血的数据模型开发指导下，Service 串联调用每一个功能模块。这些基础设施（对象、方法、接口）是被相互掉调用的。这也是因为贫血模型并没有面向对象的设计，所有的需求开发只有详细设计。
B:换到充血模型下，现在我们以一个领域功能为聚合，拆分一个领域内所需的 Service 为领域服务，VO、Req、Res 重新设计为领域对象，DAO、Redis 等持久化操作为仓储等。举例；一套账户服务中的，授信认证、开户、提额降额等，每一个都是一个独立的领域，在每个独立的领域内，创建自身领域所需的各项信息。
C:领域模型还有一个特点，它自身只关注业务功能实现，不与外部任何接口和服务直连。如；不会直接调用 DAO 操作库，也不会调用缓存操作 Redis，更不会直接引入 RPC 连接其他微服务。而是通过仓库和端口适配器，定义调用外部数据的含有出入参对象的接口标准，让基础设施层做具体的调用实现。通过这样的方式让领域只关心业务实现，同时做好防腐。
实体、聚合、值对象
原本在贫血模型下的开发，常常是不会特别在意一个方法的出入参对象的，也经常是很多个服务共用一个VO对象作为入参，只要这个对象能把我需要的属性信息带进来就可以了。

但在 DDD 的领域模型设计下，领域对象的设计是非常面向对象的。而且在整个风暴事件的四色建模过程也是在以领域对象为驱动进行的。
在这里插入图片描述
仓储和适配器
在 DDD 的设计方法中，领域层做到了只关心领域服务实现。最能体现这样设计的就是仓库和适配器的设计。通常在 Service + 数据模型的设计中，会在 Service 中引入 Redis、RPC、配置中心等各类其他外部服务。但在 DDD 中，通过仓储和适配器以及基础设施层的定义，解耦了这部分内容。

在这里插入图片描述
实现手段：

定义Repository接口：在领域层定义一个或多个Repository接口，这些接口声明了所需的数据访问方法。
实现Repository接口：在基础设施层或数据访问层实现这些接口，具体实现可能是使用ORM（对象关系映射）框架，如MyBatis、Hibernate等，或者直接使用数据库访问API，如JDBC等。
依赖注入：在应用程序中使用依赖注入（DI）来将具体的Repository实现注入到需要它们的领域服务或应用服务中。这样做可以进一步解耦领域层和数据访问层，同时也便于单元测试。
使用规范模式（Specification Pattern）：有时候，为了构建复杂的查询，可以结合使用规范模式，这是一种允许将业务规则封装为单独的业务逻辑单元的模式，这些单元可以被Repository用来构建查询。
仓储解耦的手段使用了依赖倒置的设计，所有领域需要的外部服务，不在直接引入外部的服务，而是通过定义接口的方式，让基础设施层实现领域层接口（仓储/适配器）的方式来处理。

那么也就是基础设置层负责原则对接数据库、缓存、配置中心、RPC接口、HTTP接口、MQ推送等各项资源，并承接领域服务的接口调用各项服务为领域层提供数据能力。

同时这也会体现出，领域层的实现是具有业务语义的，而到了基础设置层则没有业务语义，都是原子的方法。通过原子方法的组合为领域业务语义提供支撑。
领域编排
在 DDD 中，每一个领域都是界限上下文拆分的独立结果，而实现业务流程的功能则需要串联各个领域模块提供一整条链路的完整服务。所以也常说领域内事务一致性，领域外最终一致性。

同时这些领域模块因为是独立的，所以也可以被复用。在不同的场景功能诉求下，可以选择不同的领域模块进行组装，这个过程就像搭积木一样。

但这里有一个取舍，如果项目相对来说并不大，也没有太多的编排处理。那么可以直接让触发器层对接领域层，减少编排层后，编码会更加便捷。

好了至此DDD之理论概论点点关注不迷路老铁们！！！！！