微服务 领域驱动DDD之 服务拆分

---

前言

认识领域驱动设计DDD 、电商工程业务解读及微服务模块拆分 工程通用与配置两大基础模块

---

一、认识领域驱动设计(DDD)？

1.2 DDD 的相关概念

​ 1.DDD 是一种软件架构设计方法，它并不定义软件开发过程（DevOps）
2.DDD 利用面向对象的特性，以业务为核心驱动，而不是传统的数据库表驱动开发

1.3 理解什么是领域

​ 1.领域是对功能需求的划分;大的领域下面还有许多小的子领域

1.4 领域建模

1.分析领域模型，推演实体，值对象，领域服务
2.找出聚合边界(降低服务耦合)
3.为聚合配备存储仓库(数据持久化)
4.实践DDD 并不断推到和重构

1.5 DDD的优势

• 面向领域建模，不被某项存储技术绑架
• 领域逻辑高内聚，真正的面向对象编程。
• 不需要wiki维护，业务代码自解释，后来人员好接手
• 技术细节变更如数据库、缓存、定时器等的变更对业务逻辑影响比较小，非常适合插件式架构。本条实际上是ddd和整洁架构综合带来的优势。

1.6 DDD的收益

• 思想带来的收益，代码直接映射现实世界概念
• 整洁架构带来的收益，底层技术如框架、数据库、缓存、mq等变更不会对核心业务逻辑造成影响
• 思想带来的收益，程序员通过DDD对业务理解更加透彻，写的代码可以更好的传达客户的业务诉求
• 思想带来的收益，解耦业务、为服务化提供指导思想。架构更加清晰

1.7 DDD劣势

并不是所有的DDD都是合理的，也需要看团队和公司的规划去的。

二、使用步骤

2.电商工程微服务模块拆分

2.1 学习领域知识最好的方式就是参考和借鉴

2.2 微服务模块拆分

​ 1.工程入口及用户鉴权微服务
​ 2.网关是微服务架构的唯一入口

2.3 电商功能微服务

​ 1.四大功能微服务模块 账号 、商品 、订单、 物流等

三、业界流行的微服务拆分方法论

• 领域驱动设计 DDD（Domian Driven Design）
• 面向对象（by name./by verb. ）
• 职责划分、通用性划分
• 微服务拆分粒度
• 良好满足业务
• 增量迭代和持续进化

四、服务拆分的规范

1. 服务拆分的规范一：服务拆分最多三层，两次调用
2. 服务拆分的规范二：仅仅单向调用，严禁循环调用
3. 服务拆分的规范三：将串行调用改为并行调用，或者异步化
4. 服务拆分的规范四：接口应该实现幂等
5. 服务拆分的规范五：接口数据定义严禁内嵌，透传
6. 服务拆分的规范六：规范化工程名

---

个人总结

在我看来，微服务拆分其实目前来说没有以及具体的原则和标准可以参考，主要拆分原则遵循无非是以下几个方面：

1. 单一职责、高内聚低耦合：简单来说一张表划分为一个服务。
2. 通用性划分的形式，比如大中台 / 小中台。
3. 服务粒度适中：服务不要太细（有的团队甚至一个接口一个服务）。
4. 以业务模型切入：比如产品，用户，订单为一个模型来切入。
5. 演进式拆分：刚开始不要划分太细，可以随着迭代过程来逐步优化。
6. 避免环形依赖与双向依赖：尽量不要做服务之间的循环依赖。
7. .最重要的，要搞清楚哪些代码和配置是各个模块通用的，注意边界…