DDD基本概念

最新推荐文章于 2023-03-17 14:13:03 发布

tl211

最新推荐文章于 2023-03-17 14:13:03 发布

阅读量366

点赞数

分类专栏：架构相关文章标签： java 开发语言

本文链接：https://blog.csdn.net/tl211/article/details/126588154

版权

架构相关专栏收录该内容

2 篇文章 0 订阅

订阅专栏

这里写自定义目录标题

DDD

基本概念

服务、实体、值对象

服务：接口

实体：实体

值对象：不变的东西

贫血模型、充血模型

贫血模型：get、set实体；Service；Dao

充血模型：将领域模型的原貌直接转换为程序中领域对象的设计，这时，各种业务操作就不再在“服务”中实现了，而是在领域对象中实现。

聚合、工厂、仓库

聚合：整体与部分

聚合根：访问入口

仓库：领域模型是啥样，程序就设计成啥样。通过对象的组合，增加、删除主子表，都是由封装好的仓库来进行的。

工厂：获取对象时，由Id查询出来。查询的操作同样是交给仓库去完成。

问题域、限界上下文、上下文地图

问题域：将整个系统划分成许多相对独立的业务场景，在一个一个的业务场景中进行领域分析与建模，这样的业务场景称为 “问题子域”，简称“子域”。领域驱动核心的设计思想，就是将对软件的分析与设计还原到真实世界中，那么就要先分析和理解真实世界的业务与问题。而真实世界的业务与问题叫作 “问题域”，这里面的业务规则与知识叫 “业务领域知识”。

限界上下文：一个复杂系统的领域驱动设计，就是以子域为中心进行领域建模，绘制出一张一张的领域模型设计，然后以此作为基础指导程序设计。这一张一张的领域模型设计，称为“限界上下文”（Context Bounds，CB）。

上下文地图:限界上下文之间的这种相互关系，称为“上下文地图”（Context Map）。

限界上下文与微服务

所谓“限界上下文内的高内聚”，也就是每个限界上下文内实现的功能，都是软件变化的同一个原因的代码。因为这个原因的变化才需要修改这个限界上下文，而不是这个原因的变化就不需要修改这个限界上下文，修改与它无关。正是因为限界上下文有如此好的特性，才使得现在很多微服务团队，运用限界上下文作为微服务拆分的原则，即每个限界上下文对应一个微服务。

当多个微服务都要读取同一个表时，也就意味着同一个软件变化原因（因商品信息而变更）的代码被分散到多个微服务中。这时，当系统因该原因而变化时，代码的修改自然就会分散到多个微服务上。也就是说，以上设计问题的根源违反了“单一职责原则”，使微服务的设计不再高内聚。微服务该怎样设计、怎样拆分？关键就在于“小而专”，这里的“专”就是高内聚。

统一语言建模

注意捕获客户在描述业务过程中的那些专用术语，努力学会用这些专用术语与客户探讨业务。

事件风暴

事件即事实（Event as Fact），即在业务领域中那些已经发生的事件就是事实（fact）。分析一个信息管理系统的业务需求，就是准确地抓住业务进行过程中那些需要存储的关键事实，并围绕着这些事实进行分析设计、领域建模，这就是“事件风暴”的精髓。

在产品经理的引导下，与业务专家开始梳理当前的业务中有哪些领域事件，即已经发生并需要保存下来的那些事实。这时，是按照业务流程依次去梳理领域事件。注意，领域事件是已发生的事实，因此，在命名的时候应当采用过去时态。

橘色：事件（已下单）
蓝色：命令（下单）
黄色：人和时间
紫色：聚合关系

查询不做DDD

统一语言建模是指导思想，事件风暴会议是实践方法。

主题域、支撑域

主业务就是主题域，用户注册等就是支撑域

DDD解决微服务拆分

- 子域划分和限界上下文

通过事件风暴会议进行领域建模。
基于领域建模进行限界上下文的设计。
按照限界上下文进行微服务的拆分，按照上下文地图定义各微服务之间的接口与调用关系；
在此基础上，通过限界上下文的划分，将领域模型划分到多个问题子域，每个子域都有一个领域模型的设计；按照各子域的领域模型，基于充血模型与贫血模型设计各个微服务的业务领域层，即各自的 Service、Entity 与 Value Object；按照领域模型设计各个微服务的数据库。

- 领域事件通知：mq