首先说一下不好的思路：
1.服务拆分粒度越小越好（小服务≠微服务，实际业务需要空间换时间的，放到同一个服务里面，例如两个表之间有强关联性，不能简单地以表的操作作为服务划分的粒度）。
2.以代码量为拆分标准（服务拆分不是代码拆分）。
3.完全凭经验和感觉，或者按照别人家的套路拆分（经验和感觉也需要基于理论和实践基础）。
下面才是好的思路或者原则：
1.单一职责同时职责功能完整。
2.粒度适中，团队接受，适合公司的组织架构。
3.版本兼容性，回归测试和上线的便捷性需要考虑。
4.小步快步迭代，非一次性拆分完成。
5.精益求精，持续优化改进。
