基于 DDD 思想的应用架构 COLA 在华为服务研发的落地实践
如果无法正常显示,请先停止浏览器的去广告插件。
1. 基于DDD思想的应用架构COLA
以及华为GTS的落地实践
华为GTS 主任工程师 / 张超
2.
3. 大纲
• 从DDD思想到应用架构
• COLA应用框架
• 华为GTS的落地实践
• 思考与总结
4. 随着微服务架构的兴起,DDD正在焕发青春
微服务的边界如何划分? 边界上下文(Bounded Context)
微服务之间的依赖如何解耦? 上下文映射(Context Map)
微服务本身架构如何实现? 分层架构 (Layered Architecture)
需求理解不正确、需求变化频繁、新人接手慢 统一语言、良好的架构和设计
… …
5. 我们眼中的DDD
事件风暴
命令风暴
寻找实体
领域事件
领域划分
领域
子域
命令
支撑域
实体
值对象
通用域
聚合
限界上下文
统一语言
聚合根
…
概念多
、
操作复
杂、
落地难
!
6. DDD落地困难综合征
DDD作为一种优秀的设计思想,的确为复杂业务治理带来了曙光。然而因为DDD本身难以掌握,很容易造成DDD从
理论到工程落地之间出现巨大的鸿沟。导致很多DDD项目不仅没有治理复杂,反而造成了更多的复杂。
信心满满
开始腾飞
DDD理论
跪了…
工程落地
7. DDD工程落地的TOP困难?
战术设计
DDD认知层面:
• DDD概念复杂难以掌握;
• 团队上下认知不一,投入无法保证,难以落
入开发流程;
工程实践层面:
• 微服务如何划分,依赖如何解耦?
• 实现过程包、类无较为通用的规范,不同团
队差异较大;
• 包结构、类关系复杂、新人接手困难,
战略设计
• …
典型开发团队人员构成
10%
20%
70%
领域专家
业务专家
开发人员
应用架构是落地的关键
8. 什么是架构?
要素/组件
Architecture
Components
关系 原则
Relationships Principles
IEEE关于架构的定义:http://www.iso-architecture.org/ieee-1471/defining-architecture.html
Architecture: The fundamental organization of a system, embodied in its components,
their relationships to each other and the environment, and the principles governing its design and evolution.
架构:系统的基本组织,体现在其组件中, 它们与彼此和环境的关系,以及支配其设计和演变的原则;
9. 应用架构目的—秩序
软件的要素是代码,应用架构就是要解决代码如何被组织划分、以及后续演进规范指导的问题。
10. 大纲
• 从DDD思想到应用架构
• COLA应用框架
• 华为GTS的落地实践
• 思考与总结
11. COLA简介
Clean Object-oriented & Layered Architecture
Github 8k Star & 2k Forks
https://github.com/alibaba/COLA
…
12. COLA 4.0 整体架构
COLA v1.0
COLA v4.0
13. COLA分层设计
分离关注点,让每一层只解决该层关注的问题,从而将复杂的问题简化,起到分而治之的作
用。
14. COLA解耦设计
领域层和基础设施层的依赖通过Gateway实现依赖反转,Domain摆脱对技术细节的依赖,
专注处理业务逻辑。
DIP
15. COLA解耦设计
通过Gateway进行解耦、转义,从而确保本领域的概念完整和独立,起到防腐和隔离的作
用。不能让外领域随便“入侵”到本域。
ACL
16. COLA实践:方法论总结——上下结合,循序渐进
App层:
Use Case
1
Phase1
…
Use Case
2
Phase2
…
Phase3
Step1
Step2
Phase1
Step3
Step1
Step2
Phase2
Step3
Phase3
…
…
抽象
结构化
Domain层:
Domain Service
技术组件
方法1
方法2
方法3
方法4
分布式锁
异常处理
Domain
模型1
模型2
模型3
方
法
模型4
状态机…等等
循序渐进沉淀领域能力:1、内聚性;2、复用性;3、可理解性(业务语义表达)
17. COLA实践:方法论总结——让上帝的归上帝,凯撒的归凯撒
Adapter
Driving 技术细节
App
API
业务过程
核心业务逻辑
Domain
Gateway
Infrastructure
领域能力
Driven 技术细节
在架构的指引下,实现“核心业务逻辑” 和“技术细节”分离
18. 大纲
• 从DDD思想到应用架构
• COLA应用框架
• 华为GTS的落地实践
• 思考与总结
19. 华为GTS某产品
开发部
平台
PaaS
要素是用户、场景、功能
产品架构
DFx
业务
公共域 网络体验 市场营销
要素是员工 要素是代码功能单元
组织架构 应用架构
组织匹配
微服务
20. 产品架构的问题洞察与应对措施
产品架构导致协作、效率、治理问题频发
解决措施 = 解耦 + 抽取公共领域
业务B
核心
子域A
业务C
业务A
ACL
通用
子域B
公共能力
1.
业务和公共能力耦合:公共能力深入介入业务,导致协作
一致性成本:部分公共能力在多个业务中均有实现,功能
1.
平台认知成本:平台能力复杂,对大部分人来说,学习成
本、问题排查成本高。
SH
识别核心子域:划分界限上下文,识别网络域、业务域、营
销域、位置域等核心子域,同时构筑自己的防腐层(ACL)。
2.
重复,这就给稳定性带来了极大隐患。
3.
SH
支撑域
成本倍增。
2.
ACL
ACL
SH
核心
子域C
抽取通用子域:将告警、定界等公共能力以ServiceAPI方式
对外提供调用。
3.
抽取支撑子域:将操作日志、权限、License等通过共享内
核(Shared Kernel)以SDK的方式提供使用。
21. 应用架构的问题洞察与应对措施
1. 部分应用架构不统一,维护困难
问
题
洞
察
Demarcation App
1. 统一应用架构
DRC App
2. 部分前后端部署耦合,前端编译部署成本高
前端、后端、平台部署耦合
依赖混乱
3. 内部API不统一,可测性差
内部接口 手工API解析,缺少API规范指导
2. 统一部署架构
应
对
措
施
基于契约和规范、易维护、易理解、易测试、稳定可靠的应用整洁架构
3.统一API规范
22. 案例介绍—自动验证服务
需求背景:
由于我们的产品已经进入客户生产流,所以客户对系统和数据稳定性的要求很高,每次在升级后均需要人工进行大量用例验证;在每年上
百个客户,多次版本升级的场景下,亟需产品提供一个服务,将客户关注的系统状态、数据状态按照既定的规则进行自动验证,确保版本
升级后,数据流量稳定、流&批处理任务数据指标无异常、业务功能无异常;
需求简要分析:
用户可以根据接口定义生成请求参数,里面的字段支持按规则在运行期回填;
告警
用例编排
告警
导入
用户可以选择一个接口,定制响应数据的校验规则,如一致性检查、波动性
自动验证
检查等规则;
用户可以选择多个接口进行关联,后面接口的参数可以按规则读取前面接口
返回的结果,同时支持结果数据的连续性检查、关联度检查等规则;
查询
用户可以导入编排好的用例资产,并可以对导入的资产和用例进行管理;
用户可以从界面上创建任务,选择用例集进行执行,并对创建的任务进行管
理;
查询
查询
用户
业务1~n
调度
23. 自动验证服务—达成共识,输出统一语言
英文 中文 解释
Asset 资产 编排的测试用例资产包
Case 用例 场景化的测试用例,可能包含多个关联的接口;
Task 任务 测试用例的运行态管理实体
Interface 数据接口 API接口的信息,包含请求参数、接口类型
Request 请求参数 API接口请求参数,
ParamRule 参数规则 描述请求模板中需要替换的字段的规则;
Client 请求客户端 执行接口请求的对象,需要支持HTTP、WS等多种方式
Response 相应对象 API接口返回的结果
Check 结果检查 测试用例返回结果检查
CheckRule 结果检查规则 结果检查的规则;含准确性、波动性、连续性等;
使用
业务概念
需求文档
日常沟通
设计文档
代码
24. 自动验证服务—领域模型设计
上下文映射,通过防腐层
各个实体的依赖关系定义
告警上下文
用例编排上下文
Asset
Task
1
1
任务
执行
告警
导入
*
ACL
ACL
自动验证
Cases
*
CheckRule
1
*
ACL
1
请求结
果检查
ParamRule
查询
查询
查询
Request
业务1~n上下文
调度上下文
*
*
1
用户上下文
资产
导入
1
解析
请求
参数
1
*
Interface
执行
请求
1
1
Client
1
1
Response
Check
25. 自动验证服务--领域模型详细设计
Case聚合中请求参数、请求客户端、检查规则的设计是抽象的,方便扩展更多场景。
26. 自动验证服务--文档、设计、代码实现一致
文档
设计
统一语言
代码
27. 自动验证服务—架构守护
ArchUnit架构分层、依赖看护
public class CleanArchTest {
@Test
public void protect_clean_arch() {
JavaClasses classes = new ClassFileImporter()
.withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)
.importPackages("com.huawei.xxx");
layeredArchitecture()
.layer("adapter").definedBy("com.huawei. xxx.adapter")
.layer("application").definedBy("com.huawei. xxx.application")
.layer("domain").definedBy("com.huawei. xxx.domain")
.layer("infrastructure").definedBy("com.huawei. xxx.infrastructure")
.whereLayer("adapter").mayNotBeAccessedByAnyLayer()
.whereLayer(" application ").mayOnlyBeAccessedByLayers(" adapter ")
.whereLayer("domain").mayOnlyBeAccessedByLayers("application",
"infrastructure")
.as("The layer dependencies must be respected")
.because("we must follow the Clean Architecture principle")
.check(classes);
}
}
干净的层次依赖、领域模型之间无循环依赖
28. 大纲
• 从DDD思想到应用架构
• COLA应用框架
• 华为GTS的落地实践
• 思考与总结
29. 领域模型不是一蹴而就,需要在迭代中持续完善
失血模型 贫血模型 充血模型 胀血模型
适配层 适配层 适配层 适配层
应用层 应用层 应用层 应用层
服务 服务 服务 服务
实体 实体 实体 实体
领域层:
基础设施层
基础设施层
基础设施层
事务脚本模式:补血
Getter/Setter
原子操作
基础设施层
过犹不及:抽血
组合业务逻辑
实体间操作、持久化等
30. 组织重视+流程文化氛围牵引是DDD成功落地的保障
组织认可
跟团队领导及各领域角色一起识别落地的成本和长远的收益。
对齐DDD落地愿景,用愿景作为落地的最大内驱力。
DDD
落地经验
技术债务例行管理
团队技术决策组织,要认识到没有最优设计,只有最合适设计,保持简单设计。
例行识别技术债务,纳入管理,及时落地,防止利息膨胀;
流程文化牵引
软件不仅是技术,还是工程,从管理和流程角度也需要适配;
领域模型设计,作为开发的前置条件,防止方向错误,越走越远。
31. One More Thing:实践总结,达成持续DDD落地的4条军规
架构规范:团队核心成员一起输出产品架构、应用架构规范,软件设计必须遵守规范;
设计规范:模块第首次开发,必须输出软件设计(统一语言、领域模型、模型详细设计);如果模块有变
化,须同步刷新软件设计;同时设计中需包含测试用例设计,从业务视角保证领域对象的正确性;
文档即代码:软件设计以MD格式承载并提交到代码仓中,包名、类名跟领域模型代码实现保持一致;
持续演进:没有适用于所有场景的架构,持续重构,以代码持续CleanCode、架构持续CleanArchitecture
为目标;
32.
33.