基于DDD的微服务架构设计

基于DDD的微服务架构设计

---

1. DDD摘要&概述

每个公司都希望研发的系统具备高扩展性，以便做产品和业务迭代时，成本降到最低，效率提到最高；当下流行的微服务架构、中台架构的目标都是在不同层面去解决扩展性的问题，然而无论采用什么架构思想，要提高扩展性，都需要直面模型设计的问题；领域驱动是当下为数不多提供了模型设计框架的一个方法论，能够帮助解决一部分设计的问题，但它也不是万金油，我们需要在正确的时机和场景下使用这个方法论，才能事半功倍。

中台化的建设路径上，主要分为烟囱化、服务化、平台化、中台化四个阶段，领域驱动主要在服务化的中后期和平台化阶段发挥作用，主要贡献是提供了顶层设计框架和常见问题的横向管控手段，在使用领域驱动过程中，我们也结合业务现状，补充了一些方法，配合领域驱动一起使用，取得了较好的效果。

实施效果也达到了预期，服务 / 平台边界更加清晰，维持了一个较好的领域抽象土壤，业务的 MVP 试错成本不断降低。

1.1 DDD是什么

DDD——>Domain Driven Design
Eric Evans《领域驱动设计》一书中就提到，领域模型绝不单单是领域专家头脑中的知识，
而是对这类知识严格的组织且有选择的抽象。

1.2 基于DDD设计

通常，可以将 DDD 的设计分为 " 战略设计 / 战术设计 / 技术实现 " 三个阶段。在这三个阶段里，开发者的参与的程度是递增的。其中，战略设计阶段，
是需要众多关键角色集中投入的协作设计过程，其产出结果的质量主要取决于业务专家等角色的知识、
经验和能力，以及他们的参与程度和对DDD战略设计的思想和工具的掌握程度。
而“战术设计阶段”是需要开发者深度参与的，最后的“技术实现阶段”则要完全由开发者来掌控。

1.3 基于DDD架构和实现

重新划分领域边界，提炼出业务的核心要素进行领域建模，并采用新的应用架构分层，
创新式的选用共享内核组件和防腐层相结合的方式，解决边界上下文问题，使得某一域在读写
分离的同时，又能以组件的形式共享内核。

---

2. DDD不能解决的问题&需要注意的问题

2.1 不能解决的问题

1. 解决一小部分性能问题： 对象数，JVM内存极值，FullGC次数减少
2. DDD不能解决大部分的性能优化问题，甚至大部分的场景，我们需要为性能优化去做反DDD设计
3. DDD不能解决需求理解的问题
4. DDD不能解决开发技术水平的问题

2.2 需要注意的问题

1. DDD意识的培训
2. 充裕的对设计模式的理解
3. 老模块老办法，新模块新办法
4. 持续迭代的过程
5. 领域名词，动词分析：业务实体类，生命周期的封装，设计模式<测试模式>
6. 很大程度上会造成性能的一部分退化，考虑性能需求，颗粒度划分细致会造成性能退化；解决思路：

单个对象聚合成一个集合去处理它
做一些更大颗粒度概念的聚合

7. 合理的跨越划定我们的系统边界；技巧：

常用的是根据技术的背景去划定

8. 模型翻译，专属工具沉淀
9. 测试——单测&集成测试

重视单元测试——>service,entity层覆盖需90%，否则DDD优化后故障率会居高不下
重视集成测试——>实际逻辑分散。需尽早，多次集成，回归测试

---

3. 领域驱动与中台实践

3.1 业务架构的演变过程

烟囱——>服务化——>平台化——>中台化

业务开始阶段，就是大烟囱，业务扩展，逐渐服务化

服务化后：服务多且粒度细，不知道用哪个；公共逻辑无人管，交互越来越乱；重复造轮子；

沉淀，组合，聚合后 演变为平台

沟通成本高，逐渐演变为中台

3.2 领域驱动给的药方

1. 战略设计

• 统一语言

术语词典

• 限界上下文
• 聚合根

2. 框架设计

• 分层框架

1.http请求 ——>模型转换层：消息，定时任务
2.rpc请求——>业务流程层：公共流程，业务
3.核心服务层：领域服务，工具
4.基础数据层：领域模型，数据库

• CQRS
• 事件|行为编排

3. 战术设计

• 值对象
• 资源库
• 领域服务

4. 不能做什么

• 数据存储模型（商品的SPU—SKU模型）
• 单个具体行为的抽象（下单流程的抽象）
• 解决思路：知识+经验+模式（设计模式）