DDD实战-笔记

todo

0 开篇

中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。

 

 

 

1 微服务 DDD

 

 

 

 

 

 2 领域、子域、核心域、通用域和支撑域

DDD 的领域就是这个边界内要解 决的业务问题域。
我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细
分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是
微服务了。
核心域、支撑域和通用域的主要目标是:通过领域划分，区分不同子域在公司内的不同功能
属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一
样。

3 界定上下文

在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言
DDD 在战略设计上提出了“限界上下文”这个 概念，用来确定语义所在的领域边界。

通用语言:团队内部能够清晰、准确的描述业务模型的语言就是通用语言。 限界上下文:为通用语言划定边界，并提供语义上下文。领域内所有界限上下文的模型构 成了整个领域模型。 理论上，某些条件下，限界上下文的划分也最终确定了微服务的边界。

 

4 实体和值对象

实体有唯一ID，实体是通过ID来区分不同实体的，值对象是通过属性来区分不同值对象的，即时实体的属性都发生了改变，只要它的ID还是原来的ID，实体还是那个实体。值对象只要改变了属性值，就已经不是原来的值对象了。

在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量;在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。

 

5 聚合和聚合根

领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。

你可以这么理解，聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化

判断一个实体 是否是聚合根，你可以结合以下场景分析:是否有独立的生命周期?是否有全局唯一 ID? 是否可以创建或修改其它对象?是否有专门的模块来管这个实体。

总结：

聚合的特点:高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小 单位，但我不建议你对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作 为一个微服务，以满足版本的高频发布和极致的弹性伸缩能力。
一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了这个逻辑
边界，在微服务架构演进时就可以以聚合为单位进行拆分和组合了，微服务的架构演进也就
不再是一件难事了。
聚合根的特点:聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一 个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织 和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。
实体的特点:有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附 于聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是 一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。
值对象的特点:无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等 性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。 值对象尽量只引用值对象。

产生聚合的过程一般是，事件风暴->领域对象 ->实体、值对象->聚合根->聚合

 

 

 

6 领域事件:解耦微服务的关键

 

 

 

 

 

7 DDD分层架构:有效降低层与层之间的依赖

 

 

1.用户接口层
用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是:用户、程序、自动化测试和批处理脚本等等。

2.应用层
协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。

3.领域层
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来
实现所有与之相关的业务功能。其次，你要知道，实体和领域对象在实现业务逻辑上不是同
级的，当领域中的某些功能，单一实体(或者值对象)不能实现时，领域服务就会出马，它
可以组合聚合内的多个实体(或者值对象)，实现复杂的业务逻辑。

4.基础层
基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方
工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据
库持久化。

 

 

8  

 

 

思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑 

领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。

应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的API服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。

 软件开发中遇到的所有问题，都可以通过增加一层抽象来解决。

面向用户的展现层可以快速响应外部需求进行调整和发布，灵活多变，
应用层通过服务组合和编排实现业务流程的快速适配上线，
领域层基本就不需要太多的变化了，
如果真的万不得已要修改领域层，领域层也要遵循面向对象的6大原则(单一职则原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则），保证领域层高内聚低耦合。

 

 

中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。

 

9、中台

中台是企业级能力复用平台

 

 

10 DDD、中台和微服务：它们是如何协作的？

中台是抽象出来的业务模型，微服务是业务模型的系统实现，DDD作为方法论可以同时指导中台业务建模和微服务建设，三者相辅相成，完美结合。

DDD:
战略设计和战术设计

 

 

 

 

 

 

 

 

 

11  DDD实践：如何用DDD重构中台业务模型？

自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。
自底向上策略适用于遗留系统业务模型的演进式重构。

 

 

 

12 领域建模：如何用事件风暴构建领域模型 

DDD: 事件风暴--产品愿景--场景分析--领域建模--微服务拆分与设计。
传统: 产品需求--需求分析--详细设计--ER模型--UML设计
貌似最后都能产生模型图，一个叫领域模型，一个叫ER图，是不是关键就在这里，一个是面向业务领域建模，一个是面向底层数据层设计，也是DDD和传统的分水岭

 

13 14 代码模型

 

 

第一点：聚合之间的代码边界一定要清晰。聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。这种松耦合的代码关联，在以后业务发展和需求变更时，可以很方便地实现业务功能和聚合代码的重组，在微服务架构演进中将会起到非常重要的作用。

第二点：你一定要有代码分层的概念。写代码时一定要搞清楚代码的职责，将它放在职责对应的代码目录内。应用层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的一层，不应该有核心领域逻辑代码。领域层是业务的核心，领域模型的核心逻辑代码一定要在领域层实现。如果将核心领域逻辑代码放到应用层，你的基于DDD分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。

 

15 逻辑边界、物理边界和代码边界：

微服务架构式演进 ：
Martin Fowler 在提出微服务时，他提到了微服务的一个重要特征——演进式架构。那什么是演进式架构呢？演进式架构就是以支持增量的、非破坏的变更作为第一原则，同时支持在应用程序结构层面的多维度变化。

错误的方式： 大单体应用 小单体应用
微服务的边界： 逻辑边界、物理边界和代码边界

 

16 视图：如何实现服务和数据在微服务各层的协作？

 

 

 

 

17 从后端到前端：微服务后，前端如何设计

 

 18 实例

 

 

 

19、微服务设计和拆分要坚持哪些原则？

微服务设计原则
微服务设计原则中，如高内聚低耦合、复用、单一职责等这些常见的设计原则在此就不赘述了，我主要强调下面这几条：
第一条：要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。
第二条：要边界清晰的微服务，而不是泥球小单体。
第三条：要职能清晰的分层，而不是什么都放的大箩筐。
第四条：要做自己能hold住的微服务，而不是过度拆分的微服务。

 

微服务拆分需要考虑哪些因素？
理论上一个限界上下文内的领域模型可以被设计为微服务，但是由于领域建模主要从业务视角出发，没有考虑非业务因素，比如需求变更频率、高性能、安全、团队以及技术异构等因素，而这些非业务因素对于领域模型的系统落地也会起到决定性作用，因此在微服务拆分时我们需要重点考虑它们。我列出了以下主要因素供你参考。
1. 基于领域模型
2. 基于业务需求变化频率
3. 基于应用性能
4. 基于组织架构和团队规模
5. 基于安全边界
6. 基于技术异构等因素

 

分布式架构关键设计10问
1选择什么样的分布式数据库？
2如何设计数据库分库主键？
3数据库的数据同步和复制
4跨库关联查询如何处理？
5如何处理高频热点数据？
6前后序业务数据的处理
7数据中台与企业级数据集成
8BFF与企业级业务编排和协同
9分布式事务还是事件驱动机制？
10多中心多活的设计

 

 

ref

https://www.infoq.cn/article/s_LFUlU6ZQODd030RbH9