单体应用该如何按领域模型进行微服务化拆分？

很多团队面临这样的问题，服务到底如何拆分，怎么样的拆分是合理的，拆分后新的微服务框架和老的系统如何做兼容运行，老系统如何逐步平滑过渡到微服务架构中，而且不影响线上业务运行，也不能影响正常的项目迭代。其实，业界没有标准的方式来指导如何做拆分，我们主要围绕“拆“ 与 ”合“来做服务的拆分，所谓拆就是按业务功能拆分，所谓”合“，就是拆分后的模块经过多次迭代后可以做合并处理。比如按用户维度，按订单维度，按产品维度等，比如订单维度拆分后订单服务变更还是非常多，改动非常大，那么订单继续拆分。

个人认为您提的这个问题就是服务拆分的颗粒度问题，关于这个问题，本人此前阅读的Spring Cloud Alibaba成员姬望（彭文杰）的一篇采访稿，可能对您有所帮助，核心的观点及段落内容如下：
微服务解决的本质问题是团队分工
SOA 也好、微服务也好，解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。 你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。
这里面的概念可以网上查下，我个人觉得说的还是非常有道理的。我辖内的系统就经历了单体应用向微服务拆分的过程，拆分的背景是行内一个秒杀内的业务需要调用辖内系统应用，传统的架构性能不满足要求，故进行容器化改造，对此业务场景涉及的业务进行微服务拆分。乍看下来是业务驱动，但实际上这个系统的开发团队也因此做了拆分，安排专人服务微服务模块的开发、测试，运维方面暂未拆分。但是如果拆分的范围进一步扩大，运维团队拆分也是必然。