06 | 领域事件：解耦微服务的关键
* 背景
* 在事件风暴时，我么发现除了命令和操作等业务以外，还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在DDD中称之为领域事件。
* 定义
* 领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件，一个领域事件将导致进一步的业务操作
* 是业务流程的一个步骤，比如说触发了某些动作后的具体动作
* 如何识别领域事件
* 在分析用户场景时候，我们捕捉业务、需求人员和领域专家口中的关键词，如“发生了什么。。。则。。。”等
* 微服务内的领域事件
* 当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作
* 个人见解，可以使用spring的event 或者guava中的eventbus来实现
* 微服务之间领域事件
* 跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，其主要目的是实现微服务解耦，减轻微服务之间实时服务访问的压力。
* 实现方式就是mq了
* 弊端就是跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。
* 分布式事务机制会影响系统性能，增加微服务之间的耦合，所以我们还是要尽量避免使用分布式事务
* 领域事件的总体架构设计
* 事件包括：
* 事件的构建和发布
* 事件数据的持久化
* 事件总线
* 消息中间件
* 事件的接收和处理
07 | DDD分层架构：有效降低层与层之间的依赖
背景
- 微服务架构模型有好多种，例如整洁架构、CQRS 和六边形架构等等。每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。
- DDD 分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置 什么是DDD分层
- 用户接口层
- 用户接口层负责向用户显示信息和解释用户指令
- 应用层
- 应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作
- 应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。
- 应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
- 领域层
- 领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
- 基础层
- 基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。 DDD 分层架构如何推动架构演进？
- 微服务架构的演进
- 领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。
- 微服务内服务的演进
- 微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装 三层架构如何演进到 DDD 分层架构？
08 | 微服务架构模型：几种常见模型的对比和分析
整洁架构（洋葱架构）
- 整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
职责划分：
- 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则
- 领域服务实现涉及多个实体的复杂业务逻辑
- 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例
- 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。
- 被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
- 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
六边形架构（端口适配器架构）
六边形架构的核心理念是：应用是通过端口与外部进行交互的
职能划分如下：
- 红圈内的六边形实现应用的核心业务逻辑；
- 外六边形完成外部应用、驱动和基础资源等的交互和访问
- 对前端应用以 API 主动适配方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
三种架构模型看中台和微服务设计
- 定义
- 中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。
- 中台建设要聚焦领域模型
- 中台需要站在全企业的高度考虑能力的共享和复用。
- 微服务要有合理的架构分层
- 微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。
- 应用和资源的解耦与适配
