3.1.保留服务空间，为了将来服务的组合

在进行系统拆分的时候，对当前后端的调用都进行适当的规划，将其分为两类，一类是应用服务，一类是组合服务，这两个服务是可以在代码层面上进行抽象。重点是那些调用其他系统的地方，需要将其放入业务服务中，这块逻辑比较复杂，难以抽取，需要适当的结合”数据落地“的思路来综合考虑。有时候把一部分数据落入本地可以提升系统的整体简洁度和稳定性，但是要考虑数据的一个生命周期性质。

在迁移的过程中可能还会有一些新的功能并行开发的，既有新的逻辑需要放入新的SOA服务中，也会有迁移过来的逻辑，这两个过程同时进行其实很痛苦，尽量避免这样同时进行，但是现实是根本不可能，正常都是一起并行推进。如果这两个过程是同一组团队负责其实还好，毕竟对这块的代码、业务都比较了解。

这一节目的是想强调对现在系统进行迁移的时候要考虑服务的层次，不要只进行一个简单的搬移代码，这个时候是一个对代码进行重构的好机会，该划分层次的要划分层次，该读写分离的要读写分离，要重点考虑那些“业务服务”，需要跨越多个应用线的逻辑。

顺便说一下，还有一个重点就是迁移的时候还要考虑数据存储方面的迁移，光代码层面的迁移只是第一步，第二步还需要进行数据层面的迁移。当然这两个大的步骤都是要通过很多次迭代完成，并且还是一个对业务、代码进行很好梳理和整理的好机会。

在将系统进行服务化的时候要考虑服务层，如果当前没有业务服务的逻辑那么就保留服务空间，至少要清楚在服务层中有这么一个空间是要预留的，当有其他的应用线需要与你交互的时候可以顺利的进入到你的服务区，而不是直接到达你的应用。

4.运用DDD+GRASP进行分析和设计（防止主观的判断导致错误的假设）

做系统设计时最怕的就是职责搞错了，这会使系统的架构突然就复杂了，而且系统架构都是很难改变的或者压根就无法改变的决定。所以我对这块引起了重视，有时候你对业务在了解在熟悉依然会搞错职责，对于这块光凭主观的判断是不长远的，无发复制、无法传播的，也无法落字成文的。

对DDD我这里就不多做介绍了，这里要强调是GRASP。运用DDD可以很好的帮助我们来战略性的观察企业所坐立的领域，我还是很提倡DDD在公司实施的，不说DDD中的“战术设计”方法论，就光说它的“战略设计”方法论还是有很大作用的，让我们可以在脑海中建立一个战略性的模型。具体要不要进行代码层面的落地这就看实际情况了。而且DDD中的很多不错的思想都可以借鉴过来，包括领域通用语言，有了领域通用语言团队之间的沟通和交流会节省很多成本。对于新人来说，可以很快的了解公司的一些大概的业务，这和“词汇表”其实还是有区别的。

上面说了，在划分职责的时候很多都是通过经验来主观的判断，没有其他的客观证据了。那么有没有一个不错的方法论或模式来指导我们进行这类问题的解决呢，其实还是有的，因为在国外人家这方面已经很成熟。

GRASP就是这样的一套模式，它可以帮助我们进行客观的设计职责。到底该把这块数据放入哪个应用中，到底该把这个逻辑放入哪个服务中，都有指导，包括对对象层面的设计依然可以。我们可能对“信息专家模式”都有了解，但是以往我们可能都只把它用在对象设计上，而没有提升一个系统层面中考虑。那是因为我们以往可能没有碰见很复杂的职责分配场景，只有当出现问题时我们才能真正领会某个东西的好坏。