DDD的事件风暴第四个阶段“微服务拆分”，我们可以用限界上下文可以作为粗粒度的微服务边界，但落地时往往不得不考虑更多其他因素，比如弹性边界、安全需求、软件包大小、团队沟通效率、技术异构等等。
本阶段的
- 输入： 上阶段DDD事件风暴 - 领域建模的限界上下⽂地图
- 产出物：服务地图
在进行服务地图设计时需要考虑以下要素：
-
围绕限界上下⽂边界。
考虑业务复杂度，减少业务耦合太深。 -
考虑不同业务变化速度/相关度、发布频率。
识别领域模型中的业务需求变动频繁的功能，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离。
这是因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种分离可以有效降低频繁变动的敏态业务对稳态业务的影响。 -
考虑系统非功能性需求，如系统弹性伸缩要求、安全性要求和可⽤性要求。
比如：识别领域模型中性能压力较大的功能。因为性能要求高的功能可能会拖累其它功能，在资源要求上也会有区别，为了避免对整体性能和资源的影响，我们可以把在性能方面有较高要求的功能拆分出去。 -
考虑团队组织和沟通效率。
拆分后的微服务项目团队规模保持在10～12人左右为宜（双披萨团队）。一个微服务最好三个人维护（三个火枪手原则） -
技术和架构的异构。
由于业务场景或者技术条件的限制，有的可能用.NET，有的则是Java，有的甚至大数据架构。
对于这些存在技术异构的功能，可以考虑按照技术边界进行拆分。 -
...
用户中台服务地图
不考虑非业务因素用户中台可以设计为：用户、认证和权限三个微服务。
用户日志数据量巨大，大到需要采用大数据技术来实现，这时用户信息聚合与用户日志聚合就会有技术异构。
虽然在领域建模时，我们将他们放在一个了领域模型内，但如果考虑技术异构，这两个聚合就不适合放到同一个微服务里了。
我们可以以聚合作为拆分单位，将用户基本信息管理和用户日志管理拆分为两个技术异构的微服务，分别用不同的技术来实现它们。
请假业务场景 服务地图
按照业务拆分，我们把请假业务场景拆分成请假和考勤两个微服务。
但是人员组织关系这个是强依赖的基础服务，在其他场景会频繁的读，读流量峰值很大，而且功能稳定，需要用缓存提供一个独立的查询服务，这就演进出了一个组织关系查询微服务。
参考：
