【第十周】模块分解



• 巨无霸应用系统带来的问题

• 编译部署困难

• 代码分支管理困难

• 数据库连接过多，甚至耗尽

• 系统繁杂，新增业务困难

• 问题处理方案：

• 拆分，模块独立部署，降低系统耦合性

• 纵向：拆分独立业务

• 横向：拆分复用业务



微服务框架



• 框架需求

• 服务注册与发现

• 服务调用

• 失效转移

• 负载均衡

• 高效的远程通信

• 对应用最少侵入

• 版本管理

• Dubbo架构

• 

• Service Mesh 服务网格

• 用于服务间的通信，通常是一组轻量级网络代理，它们与应用程序部署在一起，对应用程序透明。

• sidecar模式



• 微服务架构落地

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

• 先有独立的模块，后有分布式的服务。

• 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？

• 命令与查询职责隔离（CQRS）

• 实现服务层的读写分离

• 更清晰的领域模型

• 针对读写分别优化，实现更好的性能

• 查询服务不会修改数据，更好地保护数据

• 事件溯源

• 状态变化记录到事件中

• 精确复现任何用户状态，进行复核审计

• 有效监控用户状态变化，实现分布式事务

• 断路器

• 当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求 阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务 的调用。

• 服务重试及调用超时

• 上游调用者超时时间要大于下游调用者超时时间之和。

• 最重要的是需求

• 



• 微服务网关

• 作用：

• 

• 管道技术

• 网关本身没有什么业务，主要职责是做各种校验与拦截，这些职责可以通过管道技术连 接起来。



• 开放平台网关

• API接口

• 协议转换

• 安全

• 审计

• 路由

• 流程



领域驱动设计



• 充血模型和贫血模型

• 贫血模型：Service、Dao 这些对象只有方法，没有数值成员变量，而方法调 用时传递的数值对象，比如Contract，没有方法（或者只有一些 getter、setter 方法）

• 充血模型：领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻 辑的实现，也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。和事务脚本被称作贫血模型相对应的。

• 战略设计

• 领域是一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。

• 领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。

• 子域

• 限界上下文

• 在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示 特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一 对一的关系，用来控制子域的边界，保证子域内的概念统一性。

• 通常限界上下文对应一个组件或者一个模块，或者一个微服务，一个子系统

• 上下文映射图

• 展示上下文的关联和交互

• 战术设计

• 实体

• 实体设计是 DDD 的核心所在，首先通过业务分析，识别出实体对象，然后通过相关的 业务逻辑设计实体的属性和方法。这里最重要的，是要把握住实体的特征是什么，实体 应该承担什么职责，不应该承担什么职责，分析的时候要放在业务场景和界限上下文中， 而不是想当然地认为这样的实体就应该承担这样的角色。

• 值对象

• 值对象的一个特点是不变性，一个值对象创建以后就不能再改变了

• 聚合

• 聚合是一个关联对象的集合，我们将其作为一个单元来处理数据更改。每个集合都有一个根和一个边界。

• 边界定义了聚合内部的内容。

• 根是聚合中包含的单个特定实体。

• 聚合根：将多个实体和值对象聚合在一起的实体。

• 架构

• 分层架构

• 领域实体的组合调用和事务控制在应用层。

• 

• 六边形架构

• 领域模型通过应用程序封装成一个相对比较独立的模块，而不同的外部系统则通过不同的适配器和领域模型交互，比如可以通过 HTTP 接口访问领域模型，也可以通过 Web Service 或者消息队列访问领域模型，只需要为这些不同的访问接口提供不同的适配器就可以了。

• 



• 组件设计原则

• 内聚原则

• 复用发布等同原则

• 共同封闭原则

• 共同复用原则

• 耦合原则

• 无循环依赖原则

• 稳定依赖原则

• 稳定抽象原则