1. 基于流程架构和业务架构，从跨系统交互流程出发，分析业务交互接口点，识别关键的业务服务能力。

2. 基于数据架构和主数据建模分析，识别关键的数据服务能力。

3. 基于技术架构和共性平台层技术组件的分析和定义，以能力开放原则识别关键技术服务能力。

因此对于跨系统间的集成，对于服务识别和定义思路是相对清晰的。那么在传统方法中业务系统的划分和定义粒度又是如何?在前面企业架构分析中，我曾经谈到过，通过跨系统交互流程分析，识别出最细粒度的业务功能模块和功能单元，然后再从底向上进行聚合，以CRUD分析为主要方法，多次迭代出***的满足高内聚，松耦合条件的业务系统划分。这里面没有一个精确方法，但是却有该大原则下的指导方法。

微服务模块的划分

微服务模块的划分不是什么新鲜事物，就是传统的业务系统内部的业务功能组件的划分，但是我要注意到的关键一点还是业务组件本身的粒度和大小。原来没有完全拆分为独立的微服务模块的时候，我们一个业务系统可以划分20个以上的业务模块，因为由于数据库本身没有拆分，同时业务模块间的调用本身又是内部的API调用，因此感觉不到有什么问题。但是如果把这20个业务模块完全拆分为独立的微服务模块，你才会发现模块间的紧耦合或者说大量的交互集成接口，会导致整个系统集成和交互关系相对复杂，后期很难管理。

这也是我们原来经常强调的，传统的一个大业务系统划分微服务模块的时候，尽量是划分到6到8个模块比较合适，当你本身的IT成熟度达到一定水平后你可以划分的更加细点。同时在微服务模块划分的时候一定要考虑数据库本身的划分，即底层的数据库也是划分开的，类似我原来谈私有云PaaS的时候谈的数据库的水平拆分。

究竟如何拆?实际上方法仍然是一样的，还是要分析单个业务系统内部的流程，然后分解到具体的业务组件或功能，再按照高内聚的原则进行聚合，尽量确保各个微服务模块之间的交互最少。同时对于大家都要用到的基础数据模块，仍然采用共性下沉的策略和思路进行。同时一个有价值的参考方法是，分析该业务系统承载的主体业务流程是什么?然后分析这个业务流程可以横向划分微哪几个独立的阶段，然后先将这些独立的阶段划分微不同的微服务模块，在划分好后再进行CRUD分析进行修正。