模块分解 - 微服务，组件设计原则，领域驱动开发

微服务



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

• 编译、部署困难：

• 代码分支管理困难：

• 数据库连接耗尽：

• 新增业务困难：

解决方案

• 拆分：

将模块独立部署，降低系统耦合性：



微服务框架



• Web Service 与企业级分布式服务



from wiki

处理流程：



1. 服务提供这通过WSDL向注册中心提供服务接口；

2. 注册中心使用UDDI发布服务

3. 服务请求者从注册中心发现服务后，通过SOAP与服务提供者通讯



缺点：



1. 臃肿的注册与发现机制

2. 低效的 XML 序列化手段

3. 开销相对较高的 HTTP 远程通信

4. 复杂的部署与维护手段



微服务框架需求



• 失效转移

• 负载均衡

• 高效远程通讯

• 对应用最小侵入

• 版本管理



微服务框架

• （Dubbo）架构





• Service Mesh 服务网格





微服务架构落地

• 业务先行

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

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

• 清楚实施微服务的目的是什么



最佳实践策略

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

2. 事件溯源

3. 断路器

4. 服务重试及调用超时



服务调用

• 通过服务代理



from Microservices Best Practices for Java

• 直接链接

from Microservices Best Practices for Java

• 边车模式





from Microservices Best Practices for Java

微服务网关

• API 接口

• 协议转换

• 安全：

• 审计

• 路由

• 流程：



开放授权协议 OAuth2.0





领域驱动开发



领域模型



• 事务脚本-贫血模型

没有抽象业务对象，页面驱动。



• 领域模型-充血模型



领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻 辑的实现，也就是说，设计好了领域模型对象，也就设计好了业务逻辑实现。



DDD 战略设计



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



• 子域 ： 业务上划分

• 限界上下文：物理上，对应微服务

• 上下文映射图：　模块各种依赖交互



DDD 战术设计



• 实体　：　领域对象模型

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

• 聚合：　一个关联对象的集合

• DDD 分层架构

• DDD 六边形架构

• DDD 战略设计与战术设计



组件设计原则



组件内聚原则



• 复用发布等同原则

• 共同封闭原则

• 共同复用原则

组件耦合原则

• 无循环依赖原则

• 稳定依赖原则

• 稳定抽象原则



组件的边界与依赖关系，不仅仅是技术问题



参考及引用



架构师训练营作业-李智慧老师相关讲义

Photo by Craig Adderley from Pexels

https://en.wikipedia.org/wiki/Web_service

https://philcalcado.com/2017/08/03/patternservicemesh.html

Microservices Best Practices for Java