06 | 领域事件：解耦微服务的关键
课程链接：https://time.geekbang.org/column/article/155444
在事件风暴中，除了命令和操作等业务行为，还有领域事件，这种事件发生后通常会导致进一步的业务操作。
领域事件用来白哦是领域中发生的事件。在实现业务解耦的同时，还有助于形成完整的业务闭环。例如，领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。
如何识别领域事件？在做用户旅程或场景分析时，捕捉业务、需求人员或领域专家口中的关键词：“如果发生...则...”、“当做完...的时候，请通知...”、发生...时，则...“等。这些场景发生某种时间后会触发进一步操作，那么这个事件很可能时领域事件。
领域事件驱动设计可以切断领域模型之间的强依赖关系，事件发布完成后，发布方不必关系后续订阅方事件处理是否成固，这样可以实现领域模型的解耦，维护独立性和数据一致性。在领域模型映射到微服务系统架构时，领域事件可以解耦微服务，微服务之间的数据不必要求强一致性，而是基于事件的最终一致性。
有的领域事件发生在微服务内的聚合之间，有的发生在微服务之间，还有两者皆有的场景，一般来说跨微服务的领域事件处理居多。
1.微服务内的领域事件
当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。微服务内大部分事件的结成，都发生在同一个进程内，进程自身可以很好的控制事务，因此不一定需要引入消息中间件。但一个事件如果同时更新多个聚合，就要考虑是否引入事件总线。但微服务内的事件总线，会增加开发难度。微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。这个过程会用到分布式事务，保证发布方和订阅方数据同时更新成功。
2.微服务之间的领域事件
跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，主要为了实现微服务解耦，减轻微服务之间实时访问的压力。这种场景比较多，事件处理机制也更复杂。跨微服务的事件可以推动业务流程或者数据在不同的子域或微服务间直接流转。跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还要考虑引入分布式事务。
微服务之间的访问也可以采用应用服务直接调用的方式，实现数据的服务的实施访问，弊端就是跨微服务的数据同时变更需要引入分布式事务，这样会影响系统性能，增加服务之间耦合，还是要避免使用分布式事务。
领域事件相关案例
保险承保业务。一个保单的生成，经历了很多子域、业务状态变更和跨微服务业务数据的传递。产生了很多领域事件，促成了保险业务数据、对象在不同微服务和子域之间的流转和角色转换。
如何用领域事件驱动设计来驱动承保业务流程：
事件起点：客户购买保险 - 业务完成保单录入 - 生成投保单 - 启动缴费动作。
1.投保微服务生成缴费通知单，发布第一个事件：将缴费通知单数据发布到MQ。收款微服务订阅该MQ，完成缴费操作。缴费通知单已生成，领域事件结束。
2.收款微服务缴费完成后，发布第二个事件：缴费已完成，将缴费数据发布到MQ。投保微服务收到该MQ并确认缴费完成，完成投保单转保单的操作。缴费已完成，领域事件结束。
3.投保微服务在投保单转保单完成后，发布第三个事件：保单已生成，将保单数据发布MQ。保单微服务接受到该MQ，完成保单数据保存操作。保单已生成，领域事件结束。
4.后面还会发生一系列领域事件，并发的将保单数据通过MQ发送到佣金、收付费、和再保等微服务，完成后续所有业务流程。
总之，通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个微服务之间流转，实现微服务解耦。
领域事件总体架构
领域事件的执行需要一系列组件和技术做支撑。领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接受和处理等。
1.事件构建与发布
事件基本属性至少包括：事件唯一标识、发生时间、事件类型和事件源。事件唯一标识应该是全局唯一的，以便无歧义的在多个限界上下文中传递。事件基本属性记录事件滋生以及事件发生背景的数据。时间还有业务属性，用于记录事件发生时的业务数据，会随事件传输到订阅方。事件基本属性和业务属性一起构成事件实体，事件实体依赖聚合根。领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这样在MQ中也比较容易解析和获取。
事件发布前要县构建事件实体并持久化。事件发布的方式：可以通过应用服务或领域服务发布到事件总线或者MQ，也可以从事件表中利用定时程序或数据库日志捕捉技术获取增量事件数据，发布到MQ。
2.事件数据持久化
可用于系统之间的数据队长，或实现发布方和订阅方事件数据的审计。当遇到MQ、订阅方宕机或网络中断，在问题解决后仍可继续后续业务流转，保证数据一致性。
持久化方案有两种：
- 持久化到本地业务数据库中，利用本地事务保证业务和事件数据的一致性
- 持久化到共享的事件数据库中。业务数据库和事件数据库不是一个，他们的数据持久化操作会跨数据库，因此需要分布式事务来保证业务和事件数据的强一致性。
3.事件总线（EventBus）
事件总线是实现微服务内聚合之间领域事件的重要组件，提供事件分发和接收等服务。是进程内模型，会在微服务内聚合之间遍历订阅者列表，采取同步或异步的模式传递数据。事件分发流程大致如下：
- 如果是微服务内的订阅者（其他聚合），则直接分发到指定订阅者；
- 如果是微服务外的订阅者，将事件数据保存到事件库并异步发送到消息中间件；
- 如果同时存在微服务内和外订阅者，则先处理内部订阅者，再处理外部订阅者
4.消息中间件
跨微服务的领域事件大多会用到消息中间件，实现跨微服务的事件发布和订阅。Kafka，RabbitMQ等
5.事件接收和处理
微服务订阅方再应用层采用监听机制，接收MQ中的事件数据，完成持久化后，可以开始进一步的业务处理。
领域事件运行机制案例
承保业务流程的通知缴费通知单事件为例。发生再投保和收款微服务之间。领域事件是：缴费通知单已生成。下一步业务操作是：缴费。
事件起点：出单员生成投保单，核保通过后，发起生成缴费通知单的操作。
1.投保微服务应用服务，调用聚合中的领域服务createPaymentNotice和createPaymentNoticeEvent，分别创建缴费通知单、缴费通知单事件。缴费通知单类PaymentNoticeEvent继承基类DomainEvent。
2.利用仓储服务持久化缴费通知单相关的业务和事件数据。为避免分布式事务，这些数据都持久化到本地投保微服务数据库中。
3.通过数据库日志捕获技术或定时程序，从数据库事件表中获取事件增量数据，发布到MQ。事件发布也可以通过应用服务或领域服务完成发布。
4.收款微服务再应用层从MQ订阅缴费通知单事件消息主题，监听并获取事件数据后，应用服务调用领域层的领域服务将事件数据持久化到本地数据库。
5.收款微服务调用领域岑的领域服务PayPremium，完成缴费。
6.事件结束。
提示：缴费完成后，后续还会产生很多新的领域事件。
领域事件驱动是很成熟的技术，很多分布式架构中有大量的使用。是DDD的重要概念，用领域事件驱动业务流转。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
07 | DDD分层架构：有效降低层与层之间的依赖
课程链接：https://time.geekbang.org/column/article/156849
微服务架构模型：整洁架构、CQRS、六边形架构、DDD分层架构。
DDD分层架构，最早是传统的四层架构；后来有了优化，实现各层对基础层的解耦；再后来领域层和应用层之间增加了上下文环境（Context），形成了五层架构（DCI）。
最早的四层架构中，基础层是被其他层依赖的，位于最核心的位置，但实际上领域层才是软件的核心，所以有问题。
后来采用依赖倒置（Dependency inversion principle，DIP）的设计尽心优化，实现各层对基础层的解耦。
下面是DDD分层架构：
1.用户接口层：负责向用户显示信息和解释用户指令，可以是用户、程序、自动化测试和批处理脚本等。
2.应用层：很薄，理论上不会有业务规则或逻辑，主要面向用例和流程相关的操作。位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合。另外也是微服务之间交互的通道，可以调用其他微服务的应用服务。
在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层实现。因为庞大的应用层会使领域模型失焦，时间一长微服务就会演化为传统的三层架构，会很混乱。
应用服务是在应用层的，负责服务的组合和转发，负责处理业务用例的执行顺序和结果拼装，以粗粒度的服务通过API网关向前端发布，还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
3.领域层：实现企业核心逻辑，保证业务正确性。主要体现模型的业务能力。
包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。其次，实体和领域模型在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
4.基础层：贯穿所有，为其他各层提供通用的技术和基础服务，如第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库。它包含基础服务，采用依赖倒置设计，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。例如传统架构中，最担忧的就是换数据库，因为可能要重写大部分代码。采用依赖倒置的设计后，应用层就可以通过解耦来保持独立的核心业务逻辑。数据库变更时，只需要更换数据库基础服务就可以了。
DDD分层架构的重要原则：每层只能与位于其下方的层发生耦合。
架构根据解耦的紧密程度可以分成两种：严格分层架构和松散分层架构。优化后的DDD分层架构就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。传统的DDD分层架构属于松散分层架构，允许某层与任意下方的层发生依赖。推荐选择严格分层架构，领域服务只能被应用服务调用，应用服务只能被用户接口层调用，服务逐层对外封装或组合，关系清晰。但是松散分层架构中领域服务可以同时被应用层和用户接口层调用，关系复杂难以管理，甚至容易使核心业务逻辑外泄。
如果领域层中的某个服务发生了重大变更，在严格分层架构中，只需要逐层通知上层服务就可以了。
DDD分层架构推动架构演进
1.微服务架构的演进
领域模型中对象的层次从内到外依次是：值对象、实体、聚合、限界上下文。
实体或值对象的简单变更，一般不会使领域模型和微服务发生大的变化。但聚合的重组或拆分却可以。因为聚合内业务功能内聚，能独立完成特定的业务逻辑。可以以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可以作为一个整体在不同的领域模型之间重组或拆分，或者直接将一个聚合独立为微服务。
上图为例：①当发现微服务1中的聚合a的功能被高频访问，甚至拖垮整个微服务1的性能，可以把聚合a的代码，独立为微服务2，它可以轻松应对高性能场景；②发现微服务3的领域模型有了变化，聚合d更适合放到微服务1中。可以将d整体搬迁到微服务1中，如果合计时已经定义好了聚合之间的代码边界，这个过程不会太复杂。③经历模型和架构演进后，微服务1已经从最初包含聚合a、b、c，演进为包含聚合b、c、d。
怎么实现聚合代码快速重组呢？后面实战再讲。
2.微服务内服务的演进
微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装。在逐层组合和封装时，会出现：
服务设计时，并不一定能完整预测有哪些下层服务会被多少个上层服务组装，因此领域层通常只提供一些原子服务，比如领域服务 a、b、c。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你会发现领域服务 b 和 c 同时多次被多个应用服务调用了，执行顺序也基本一致。这时你可以考虑将 b 和 c 合并，再将应用服务中 b、c 的功能下沉到领域层，演进为新的领域服务（b+c）。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。服务演进的过程是随着系统发展的。
三层架构如何演进到DDD分层架构？
首先，由于层间松耦合，我们可以专注于本层的设计，而不必关心其它层，也不必担心自己的设计会影响其它层。DDD 成功地降低了层与层之间的依赖。其次，分层架构使得程序结构变得清晰，升级和维护更加容易。我们修改某层代码时，只要本层的接口参数不变，其它层可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。
该怎样转向DDD分层架构？
传统企业应用大多是单体架构，而单体架构则大多是三层架构。三层架构解决了程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念，在物理上它是中心化的集中式架构，并不适合分布式微服务架构。DDD 分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。
首先，架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
08 | 微服务架构模型：几种常见模型的对比和分析
课程链接：https://time.geekbang.org/column/article/158248
对比DDD分层架构、整洁架构、六边形架构。
整洁架构
又名“洋葱架构”，体现了分层分设计思想。在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
在洋葱架构中，各层的职能是这样划分的：
- 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
- 领域服务实现涉及多个实体的复杂业务逻辑。
- 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
- 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
- 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
六边形架构
又名“端口适配器架构”，是微服务架构的渊源。六边形架构的核心理念是：应用是通过端口与外部进行交互的。这也是微服务架构下 API 网关盛行的主要原因。也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。
- 红圈内的六边形实现应用的核心业务逻辑；
- 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。
三种微服务架构模型的对比和分析
虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样，但这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想。
图中的红色线框，三种架构中都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中划分了应用层和领域层，来承担不同的业务逻辑。领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变。但总体来说，不管前端如何变化，在企业没有大的变革的情况下，核心领域逻辑基本不会大变，所以领域模型相对稳定，而用例和流程则会随着外部应用需求而随时调整。把握好这个规律，我们就知道该如何设计应用层和领域层了。架构模型通过分层的方式来控制需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。这样设计的好处很明显了，就是可以保证领域层的核心业务逻辑不会因为外部需求和流程的变动而调整，对于建立前台灵活、中台稳固的架构很有帮助。
中台和微服务设计的关键：领域模型和微服务的合理分层设计。
从三种架构模型看中台和微服务设计
中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。中台作为子域还可以继续分解为子子域，在子域分解到合适大小，通过事件风暴划分限界上下文以后，就可以定义微服务了，微服务用来实现中台的能力。表面上看，DDD、中台、微服务这三者之间似乎没什么关联，实际上它们的关系是非常紧密的，组合在一起可以作为一个理论体系用于中台和微服务设计。
1. 中台建设要聚焦领域模型
中台需要站在全企业的高度考虑能力的共享和复用。中台设计时，我们需要建立中台内所有限界上下文的领域模型，DDD 建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。因此，在中台设计中我们首先要聚焦领域模型，将它放在核心位置。
2.微服务要有合理的架构分层
微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。也不要把领域模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终领域模型会失焦。如果实在无法避免，我们可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃。微服务内部的分层方式我们已经清楚了，那微服务之间是否也有层次依赖关系呢？如何实现微服务之间的服务集成？有的微服务可以与前端应用集成，一起完成特定的业务，这是项目级微服务。而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才能完成，这是企业级中台微服务。两类微服务由于复杂度不一样，集成方式也会有差异。
项目级微服务：项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离。但项目级的微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 中红色框内的应用服务 B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
企业级中台微服务：企业级的业务流程往往是多个中台微服务一起协作完成的，企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。我们可以在中台微服务之上增加一层，下面这张图，增加的这一层就位于红色框内，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配。如果再将它的业务范围扩大一些，我可以将它做成一个面向不同行业和渠道的服务平台。我们不妨借用 BFF（服务于前端的后端，Backend for Frontends）这个词，暂且称它为 BFF 微服务。BFF 微服务与其它微服务存在较大的差异，就是它没有领域模型，因此这个微服务内也不会有领域层。BFF 微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可以适配不同前端和渠道的要求。
3. 应用和资源的解耦与适配
传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。正是由于它们之间的这种强依赖的关系，我们一旦更换基础资源就会对应用产生很大的影响，因此需要为应用和资源解耦。在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的。在应用设计中，我们会同步考虑和基础资源的代码适配，那么一旦基础设施资源出现变更（比如换数据库），就可以屏蔽资源变更对业务代码的影响，切断业务逻辑对基础资源的依赖，最终降低资源变更对应用的影响。
DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦。
