架构设计：业务域的拆分

一、拆分原则

服务拆分过细导致的问题：

1、性能下降

2、问题定位难度增加

服务粒度匹配团队规模

最佳实践：

1、扩展期：3人对应1个服务

2、维护期：2人对应多个服务

演进式拆分原则

 以模型职责拆分（基于业务逻辑为主）

关注点

数据库拆分后数据一致行问题

解决方案：最终一致性来替代分布式事物

实现方式：可靠事件模式（不断重试）；补偿模式（补偿/回滚）

二、服务拆分的真实案例解析

拆分需要主要的问题

如何将结构提拆分为服务化架构

识别业务领域及边界

领域划分的一些经验

拆分的策略

最常用的做法

拆分业务如何支持业务扩展

如何安全持续拆分

如何保证拆对了

某教育产品服务化拆分

拆分反例

三、识别业务领域模型及边界

什么是领域模型驱动

领域模型属于解决方法空间

大白话：请假系统是解决人力资源工时问题，属于人力资源领域；电商平台是解决消费者购物问题，属于电商领域

概念介绍

采用领域驱动设计好处

系统的复杂度体现优势

传统软件开发模型

什么是领域驱动设计

领域模型驱动设计相关概念

战略建模&战术建模

问题空间&解决方案空间

核心域&支撑子域&通用子域

理解界限上下文

上下文映射图

领域实体

实体和值对象

聚合（根实体，持久化对象）

聚合根

领域服务

领域事件

例如：银行转账事件

领域建模例子

四、领域建模和划分边界的常见方法

用例法建模

基于用例法建模的步骤

用例的识别及表达

B最好的描述

用例示例

推荐用例4

用例法实践

收集名称

构建类与属性

完善类与属性

添加类关联

最终建模结果

事件风暴

1、识别领域建模事件

2、识别领域命令

3、寻找聚合

4、领域边界确认

领域专家、产品、开发人员

四色建模

问题

还原真相

五、领域建模的架构方法和经验

经典的分层架构

六边形架构

领域层鱼技术层关系

在六边形架构中，领域层跟技术层没有关系。可以看作是业务的技术实现，端口层包裹在领域层外，外部要与领域成通信，必须通过接口层来“首肯”。反过来，领域层与外部通信也需要经过接口层。但这种方式一般在技术上的，比如领域对象的管理。

六边形架构鱼SOA、Restful的关系

CQRS-命令查询职责分离

CQRS

事件驱动架构

领域事件

领域事件例子

整体架构

六、电商领域建模案例解析

业务中台定义

中台VS平台

领域建模构建业务中台

建模阶段

实施阶段

选型分层架构

架构动态视角

工程规范

演进

领域建模案例

系统设计

事件案例

领域命令

领域聚合

领域边界

输出领域模型

指导架构及开发

业务重构

业务背景

订单数据域

转自公众号：Dawn持续输出