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.