对于模块的拆分包括两部分：数据库与业务代码，可以先数据库后业务代码，亦可先业务代码后数据库。然而我们的项目拆分中遇到的最大挑战是数据层的拆分。在2015年的拆分中发现，数据库层由于当时系统性能调优的驱动，在代码中出现了跨模块的数据库连表查询。这导致后期服务的拆分非常的困难。因此在拆分步骤上我们更多的推荐数据库先行。

　　4.数据库拆分

　　我们借鉴了一书中提到的方法，通过重复schema同步数据，对数据库的读写操作分别进行迁移。如下图所示：

　　虽然技术上是可行的，然而这仍然占用了大量不必要的时间，包括大量的数据迁移。这也是导致当时的拆分无法在给定时间内完成的很大因素。

　　5. 我们的结果：

　　系统架构图：

　　问题2：拆分后业务变了增加了怎么办？

　　随着客户业务的变化，我们的服务也在持续的增加，而其中碰到了一个特大的服务。服务的大小如何衡量呢？该服务生产代码7万行+，测试代码14万行+，测试运行时间2个小时。团队中7个stream每天50%工作需要对这个服务进行更改，使得团队间的依赖非常严重，独立功能无法单独快速前行，交付速度及质量都受到了影响。

　　我们的总结：

　　客户的业务是在变化的，我们对业务的认知也是逐渐的过程，所以Martin Fowler在他的文章中提出，系统的初期建议以单体结构开始，随业务发展决定其是否被拆分或合并。那么这也意味着这样构建的服务在它的生命周期中必然会持续被拆分或合并。那么为了实现这样一个目标，使系统拥有快速的响应力，也要求这样的拆分必然是高效的低成本的。

　　因此，服务的设计需要满足如下的原则：

服务要有明确的业务边界，以单体开始并不意味着没有边界。

　　服务要有边界，即使以单体开始也要定义单体时期的边界。我们系统中有一个名为“Monkey”的服务，是在中国虎年启动的，由此它并不是一个业务概念。当这个服务的名字为MonkeyAPI时，可以想象5年来它变成了什么？几乎所有和这个产品相关的功能都放入了这个服务中。脱离平台来看这一个产品的系统，其实它只是做了前后端分离而已。这个例子告诉我们，没有边界就会导致大杂烩，之后对其进行整理和重造的代价很大，可能需要花费“几代人”的努力。

服务要有明确清晰的契约设计，即对外提供的业务能力。

服务内部要保持高度模块化，才能够容易的被拆分。

可测试。

　　就如前言中提到的，系统已经上线大量的用户正在使用，如何在不影响当下系统运行状态的前提下，持续安全地演进？其实持续演进就是一场架构层次的重构，在这样的路上同样需要：

坏味道驱动，架构的坏味道是代码坏味道在更高层次的展现，也就意味着架构的混乱程度同样反映了该系统代码层的质量问题。

安全小步的重构。

有足够的测试进行保护——契约测试。

持续验证演进的方向。

　　拆分不能没有目标，尤其在具有风险的架构层次拆分更需谨慎。那么我们如何验证拆分的结果和收益？或许它可以提高开发效率，交付速度快，上线快，宕机时间也短，还能提高开发质量，可扩展性好，稳定，维护成本低，新人成长快，团队容易掌握等等。然而软件开发是一个复杂的事情，拆分可以引起多个维度的变化，度量的难度在于如何准确定位由拆分这一单一因素引起的价值的变化（增加或降低）。

　　其实要回答这个问题，还是要回到拆分之初：为什么而拆？

　　我所见过的案例中有因为政治原因拆的、业务发展需要的、系统集成驱动的等等；有因之而成功的，也有因之而失败的。拆并不是一件容易的事，有诸多的因素。我认为不管表象是什么，拆之前需要弄清拆分的价值所在，这也是我们可以保证拆分结果的源头。

　　总结

　　系统可由单体结构开始，不断的演进。而团队需要对业务保持敏感，与客户、业务人员进行业务对话，不断修炼领域驱动设计和重构的能力。