领域驱动模型(DDD)设计讲解

一. 什么是领域驱动模型(DDD)？
领域驱动模型一种设计思想，我们又称为DDD设计思想。是一种为了解决传统设计思想带来的维护困难，沟通困难和交互困难而产生的一种新的思想。也解决了在部分公司中，一个项目组就是一套服务，不同项目组中又相互通过RPC访问，相互之间交互的安全保障。

二. 领域驱动模型解决了什么问题
在传统微服务的单服务设计上，我们通常只顾自己开发，只顾自己业务，只管理自己数据库，一旦其他服务需要使用另一个服务上的某些功能时，我们通常需要使用HTTP来内网访问达到目的，或是使用RPC来访问业务。首先假设我们需要用HTTP来访问其他服务接口，首先，我们需要知道对应服务的URL，其次需要开发方提供对应的参数VO，一旦VO变化，开发方忘记通知下游业务方，下游业务方是无法感知的。接下来会讲解模型中每一层概念，会一步步证明领域驱动模型的出现，降低了微服务下，服务之间的耦合程度，提高了内聚力。

三. 设计领域驱动模型
传统设计模型：

领域驱动模型：

以下介绍的层级，即是领域驱动模型中代表的各个领域，去负责自己的范围：
API层：
作用：存放要对外暴露的RPC接口的service层。
意义：其他服务不需要了解自身服务的业务实现，这一层很薄，只需要提供出去，其他服务知道它是干嘛的，就足够了，即让其他服务调用了自身业务，又没有暴露自身的业务实现，降低安全风险。

Web层：
作用：可以对等于传统设计的controller层，用来处理参数校验，转发等一些简单的业务。
意义：与Service层剥离，其目的是为了保障biz层的独立性，但是在maven结构中又引用biz层，可以理解为biz的下游，当需要biz处理业务的时候，通知biz帮忙处理，但是不参与biz层的业务实现，只提交对应参数。

Biz层：
作用：biz是Business的缩写，即业务逻辑层，可以对等于传统设计的Service层，存放的业务逻辑，biz中也存在service，biz中的service存放的是内部使用，不对外提供的service。api层和biz层的service业务逻辑实现都存放在biz层中。
意义：剥离业务逻辑，防止业务逻辑暴露，同时与dal层剥离，保证自身独立性，不与dal层耦合。这一层也是服务核心层，是处理下游提交的需求与数据之间交互的重要层级。

dal层：
作用：dal是Data Access Layer的英文缩写，即数据访问层，可以对等于传统设计的Dao层，主要是用来负责与数据的交互，比如Mysql、ES、HBase等。通常我们的Mybatis的Mapper和JPA就在这一层编写。
意义：让业务与数据隔离，dal层成为了biz层的上游，负责为biz的业务实现提供对应数据。同时dal与数据中间件直接映射，形成绑定关系，其他服务需要接手数据层，可以直接引用，达到高内聚的目的，又降低了代码的耦合性，提高了开发效率。

domain层：
作用：存放一些通用的，可以对外暴露的Object、Enum等。
意义：通常用来制定一些标准，比如共同使用的枚举、常量的定义，一般作为上游服务，提供给下游服务，需要按照标准实施的内容。

config层：
作用：存放一些通用的配置，如缓存、中间件、日志和消息消费等通用配置，注意一点的是，消息消费简单的处理是放在该层，涉及到本服务数据交互的业务，还是需要写在biz层，在biz中去实现较为复杂的业务，消息消费放在该层中也是为了便于维护。
意义：配置独立化，便于管理与维护。

client层：
作用：存放调用第三放平台，外部服务等RPC或HTTP接口服务等。如通过pom引入其他服务的api层，编写调用http接口的实现，但与本服务数据交互的业务仍在biz层中实现。
意义：第三方内容独立化，便于管理与维护。
————————————————
版权声明：本文为CSDN博主「李小熊Zz」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_37743433/article/details/109536357