微服务的划分

当业务复杂度足够高的时候，应该基于领域驱动划分服务，而领域驱动本身足够复杂，很多概念比较抽象，应用范围并不是特别广泛，所以当业务复杂度较低时，可以选择基于数据驱动划分服务。数据驱动更容易理解和上手。

1. 基于数据驱动划分
2. 基于[[领域驱动设计]]划分 DDD
   1. 使用统一的语言理解需求，最好是业务语言而不是技术语言。
   2. 业务分析
   3. 寻找聚合，可以通过事件风暴来寻找聚合，将一系列的事件、动作聚合成一个领域
   4. 确定服务的调用关系
   5. 业务流程验证
      1. 服务划分是否合理？
      2. 如果一次调用要跨多个服务，怎么保证一致性？
      3. 性能是否达标？
3. 从单体架构中逐步分离
   1. 先分割前后端，不过目前的开发架构都已经默认是前后端分离的，所以对于新应用来说这一步是默认完成的。
   2. 在剥离出公共服务，比如单点登录。因为公共服务的边界清洗，耦合度低
   3. 再抽象出核心服务

判断服务划分是否合理：

1. 一个小功能的上线需要多久，是否能够在几天内完成？如果需要的时间太久，可能就是划分的颗粒度不足。
2. 大多数功能的修改是否能够在一个服务内部完成，如果修改一个功能，要修改多个服务，可能就存在划分不合理的情况。