业务类别因素

• 松耦合、高内聚，服务化子系统之间的依赖最小化，基于DDD的限界上下文（Bounded Context）将同一业务实体提供的业务服务划分在同一个子系统中；
• 考虑业务变更频率，将变化频度高与变化频度低的业务服务分组在不同的服务化子系统中；
• 确保服务子系统功能完整性、职责单一性;
• 围绕业务功能对业务子领域进行垂直和水平拆分，形成业务子系统；

技术类别因素

• 在将服务划分到不同的服务化子系统时，减少分布式数据库事务；
• 根据服务对数据一致性的要求，如实时一致性还是最终一致性，划分服务子系统；
• 根据技术栈划分子系统，一个子系统中避免使用两种或以上技术栈类型的服务；
• 根据数据库类别划分子系统，一个子系统中尽量减少使用两种或以上的数据库类型的服务；
• 划分服务子系统时，避免服务间出现循环依赖、双向依赖的问题， 永远只有不同层级的单向依赖，也就是，高层服务可以依赖低层服务，同层服务间不互相依赖；

运维类别因素

• 考虑业务服务的资源占用情况，根据CPU与内存的占用类别与占用大小，将业务服务进行分组在不同的子系统中，以便将来可以对资源占用率高的业务服务动态横向扩展；
• 服务子系统的划分应与DevOps 团队规模与交付步频率相匹配；
• 迭代演进，非一蹴而就。