责任申明

本文部分资料来源《极客时间的领域驱动设计课程》，目前是一门讲 DDD 的课程，大家可以去购买！我这里通过自己的理解进行下笔记整理和如何应用我们的业务系统场景。

另外资料来源领域驱动设计书和 B 站上的 DDD 领域驱动设计分享。地址传送门：https://www.bilibili.com/video/BV1pf4y1Y75t

一、解藕微服务·事件驱动

我们经常在工作中用到的解藕中间件是什么？消息队列 MQ，没错。就是它。而我们从上篇文章

DDD 领域驱动设计·学习应用·一中提到的聚合实际上就是我们划分领域以后的模块或者微服务。

回顾下我们之前的图。

1.1、微服务内模块之间·事件驱动

可以通过跨聚合的服务编排和启动，以服务调用的方式完成跨聚合访问，应用于实时性和数据一致性比较强的场景。

1.2、微服务服务之间·事件驱动

微服务之间通过事件驱动比如说下单模块会经历-订单服务、库存服务、物流服务、履约服务。那么在支付的同时，我们可以将消息通过消息的方式进行多个服务执行。

1.3、领域事件总架构

1.4、领域驱动设计的应用案例

二、分层架构

2.1、初期四层架构（view-controller-service-domain）

在领域驱动设计书中，我们之前的文章讲过分层架构一共四层。

但是我们也提到过架构是演进的，那么在大家不断摸索过程中，对架构进行了升级。

2.2、优化后四层架构（保留意见）

这里是作者提出的：希望将核心放到领域层，而不是基础层。这个感觉应该不是在于图的区别核心，所以保留意见。比如接下来的一张图来自作者

2.3、分层原则

DDD 分层架构原则：每层只能与下方的层发生耦合。

这里的疑问：为什么要严格区分层，我们的初期四层架构中是可以从上到下调用的，这里的答案其实就是为了实现聚合原则，我们尽可能希望便于管理服务的依赖关系和防止核心业务逻辑外泄。这里依然还是我们的架构设计原则高内聚、低耦合、单一职责原则、迪米特法则和开闭原则等的应用。

案例比如我们的实际例子如下图，其实就如同我们的类的抽象+复用原则一样，如果领域层的服务可以合并就需要合并聚合，这样不仅简化服务而且对于之后拆分服务的边界上下文是有很好的帮助。

2.4、案例（三层架构升级到领域驱动四层架构）

2.5、回顾架构设计思想

2.5.1、洋葱架构（简洁架构）

我们现在在回头看架构设计思想，发现基础资源+用户界面在最外层，接下来是应用服务层最后是领域服务核心领域模型。

2.5.2、六边形架构

六边形架构主要是将其分为内六边形和外六边形。

2.5.3、DDD 风层四层架构和洋葱、六边形架构的共同点

2.6、案例

2.6.1、微服务架构

2.6.2、中台服务架构

2.6.3、中台和微服务

2.6.4、战略设计+战术设计

2.6.5、业务领域划分模版

2.7、演进中的微服务架构

2.7.1、微服务演进的策略

绞杀者策略：类似建筑拆迁，完成部分建筑物的新建，然后拆除部分旧的

修缮者策略：类似古建筑，缝缝补补而已

2.7.2、微服务拆分考虑因素

• 基于领域模型

• 基于业务需求变化

• 基于应用性能

• 基于组织架构和团队规模

• 基于安全边界

• 基于技术异构因素

2.8、不同边界划分方式

2.9、微服务项目代码模版案例

三、实际案例记录