拆分
拆分的目的是为了将单体架构服务拆分为分布式架构，例如服务化架构，或者微服务架构。通常，如果要拆分为微服务，会先过渡到服务化架构。
拆分有两种思路：基于组件（Component Based）或基于战术分叉（Tactical Forking）。
基于组件的拆分
基于组件的拆分把系统拆成高内聚、松耦合的组件。
它有多种模式，分别应对拆分中的不同问题。选定某种模式后，可用对应的 fitness function 约束后续实现，使之符合该模式。
| 模式 | 一句话概括 | 适应度函数 |
|---|---|---|
| Identify and Size Components | 识别现有组件并度量其规模（如代码行/类/函数数），计算标准差；对明显高于标准差的组件做进一步拆分 | 以（代码行/类/函数数量）的标准差为度量 |
| Gather Common Domain Components | 提炼公共域 | 1. 项目树叶子节点中的重复名称 2. 跨组件的重复代码量 |
| Flatten Components | 仅用叶子目录表示一个组件，使组件平铺、无嵌套。若组件内有嵌套目录：1）将子目录合并到父目录成一个大组件；2）在父目录下新建 shared 目录作为新组件，存放原共享代码 | 域的根目录只含子目录，不含代码 |
| Determine Component Dependencies | 分析组件依赖、评估拆分难度；shared 组件作为公共库而非服务时可排除 | 约束依赖方向，如禁止某包依赖某包 |
| Create Component Domains | 按域组织功能相关组件，为单体到服务化过渡做准备 | 业务代码须落在现有域内；新建域时告警 |
| Create Domain Services | 组件按上述模式组织后，可拆出领域服务，完成单体到服务化 | 领域服务的 namespace/package 须以该域名为前缀，如 ..ss.ticket.. |
战术分叉
战术分叉将源码 Fork 出多份，分给多个团队，根据各自业务对单体服务进行裁剪，最终得到特定领域的服务。
