【九月打卡】第二天 设计电商工程,把握全局视角

第一模块：

课程名称：Spring Cloud / Alibaba 微服务架构实战

课程章节： 第三章 设计电商工程,把握全局视角

主讲老师：张勤一

第二模块：

今天学习的内容包括：

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

第三模块：

认识领域驱动设计(DDD)

1.1 什么是领域驱动设计(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. 最重要的，要搞清楚哪些代码和配置是各个模块通用的，注意边界…

3.今天学习课程共用了2个小时，重新学习一下 设计电商工程,把握全局视角 大家一起加油