这一节目的是想强调对现在系统进行迁移的时候要考虑服务的层次，不要只进行一个简单的搬移代码，这个时候是一个对代码进行重构的好机会，该划分层次的要划分层次，该读写分离的要读写分离，要重点考虑那些“业务服务”，需要跨越多个应用线的逻辑。
顺便说一下，还有一个重点就是迁移的时候还要考虑数据存储方面的迁移，光代码层面的迁移只是第一步，第二步还需要进行数据层面的迁移。当然这两个大的步骤都是要通过很多次迭代完成，并且还是一个对业务、代码进行很好梳理和整理的好机会。
在将系统进行服务化的时候要考虑服务层，如果当前没有业务服务的逻辑那么就保留服务空间，至少要清楚在服务层中有这么一个空间是要预留的，当有其他的应用线需要与你交互的时候可以顺利的进入到你的服务区，而不是直接到达你的应用。
4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设)
做系统设计时最怕的就是职责搞错了，这会使系统的架构突然就复杂了，而且系统架构都是很难改变的或者压根就无法改变的决定。所以我对这块引起了重视，有时候你对业务在了解在熟悉依然会搞错职责，对于这块光凭主观的判断是不长远的，无发复制、无法传播的，也无法落字成文的。
对DDD我这里就不多做介绍了，这里要强调是GRASP。运用DDD可以很好的帮助我们来战略性的观察企业所坐立的领域，我还是很提倡DDD在公司实施的，不说DDD中的“战术设计”方法论，就光说它的“战略设计”方法论还是有很大作用的，让我们可以在脑海中建立一个战略性的模型。具体要不要进行代码层面的落地这就看实际情况了。而且DDD中的很多不错的思想都可以借鉴过来，包括领域通用语言，有了领域通用语言团队之间的沟通和交流会节省很多成本。对于新人来说，可以很快的了解公司的一些大概的业务，这和“词汇表”其实还是有区别的。
上面说了，在划分职责的时候很多都是通过经验来主观的判断，没有其他的客观证据了。那么有没有一个不错的方法论或模式来指导我们进行这类问题的解决呢，其实还是有的，因为在国外人家这方面已经很成熟。
GRASP就是这样的一套模式，它可以帮助我们进行客观的设计职责。到底该把这块数据放入哪个应用中，到底该把这个逻辑放入哪个服务中，都有指导，包括对对象层面的设计依然可以。我们可能对“信息专家模式”都有了解，但是以往我们可能都只把它用在对象设计上，而没有提升一个系统层面中考虑。那是因为我们以往可能没有碰见很复杂的职责分配场景，只有当出现问题时我们才能真正领会某个东西的好坏。
DDD只有结合GRASP才能客观准确的方配某个领域的职责，不管是战略设计层面还是战术设计层面，都是一个很好的平衡标准，不会由于技术人员主观的兴趣倾向导致一个错误的职责分配决定，而这个错误的决定最终是要开发人员来买单。
5.SOA分布式下的数据一致性
传统分布式系统与当代的面向SOA的分布式系统有一定区别，论概念上来讲SOA是以服务为中心，既然以服务为中心就会有很多面向服务的设计原则。而传统的分布式系统没有服务的概念，也没有所谓的一切皆是服务的原则。而当代SOA则首要原则就要以服务为中心，针对服务的设计又有了很多服务设计原则。
SOA对服务还进行了类型的划分，按照服务的应用层次来分类：业务服务、组合服务、应用服务，包装服务等。再按照管理与运维的层面来分类：控制服务、调度服务、监控服务等等。传统的分布式系统是没有这些的，我们谈论的是当代SOA的分布式系统，所以我们强调的是以服务为中心，以服务设计原则为架构设计的指导要求，当代SOA是对传统分布式系统的一个迭代进化，不是一个时代的产物，SOA更加强调了以服务为首要原则，已经提升到了另外一个更加高级的层面。
本节我们交流一下在当代SOA分布式系统中的数据一致性问题，在SOA中这主要涉及两个层面来考虑，一个是服务层面、一个数据持久化层面。再按照一致性的基本要求，可以分为：读一致性、写一致性、会话一致性、最终一致性、实时一致性等几个维度，当然还有其他几个维度的一致性要求。
我们这里重点讨论在企业应用中实施SOA时遇到的一些比较棘手的数据一致性问题和解决方案，对于刚才提到的几个维度的一致性要求均具有重要的参考价值。