当然领域驱动设计在落地的过程中可能存在各种问题，比如前期规划时间过长，前期设计阶段考虑不到细节的场景，落地的时候会经常碰到和前期设计不一致的地方，需要返工等现象。其实互联网公司也大多没有安装领域驱动设计的完整流程来做，但是这里面的流程梳理和领域划分，还是很必要的。
领域划分好了，接下来就要开始拆分出服务，进行服务化了。从哪里入手呢？比较落地的方法是随着新需求的不断到来，渐进的进行拆分，而变化多，复用性是两大考虑要素。
这么说有点虚，我们举个现实的例子。例如按照领域的划分，对于电商业务来讲，一个单体的Online服务，应该拆分成下面这些服务。
但是绝不是发起一项运动，闭门三个月，一下子都拆分出来，一方面没有相应的工具链，流程，员工的能力的适配，将使得服务化失控，这也是我们经常观察到，很多企业服务化之后，一下子失控，从而不断的加班，业务SLA降低，需求接的更慢了等现象，然后就放弃了服务化，回归单体应用，然后骂中台，微服务是垃圾。
领域驱动设计的结果仅仅是一个规划，使得后台的技术人员在和业务的领域专家讨论业务流程和场景的时候，对于业务有更深入的理解，并且通过DDD的输出有一个完整的地图。但是接下来后台技术部门不应该闷头开始就按这个拆了。因为领域知识从业务部门到技术部门的传递一定有信息的丢失，这也是DDD落地被诟病的地方，就是业务方规划的时候是这样说的，落地来需求的时候，却是另外一种说法，导致根据DDD落地好的领域，接需求接的更加困难了。
所以赵本山说，不看广告，看疗效。对于服务拆分，DDD是一个完整的地图，但是具体怎么走，要不要调整，需要随着新需求的不断到来，渐进的进行拆分，DDD领域设计的时候，业务方会说不清，但是真的需求来的时候，却是实实在在的，甚至接口和原型都能做出来跟业务看。
需求到来的时候，技术部门是能感受到上一节讲过的架构耦合导致的两个现象：
-
耦合现象一：你改代码，你要上线，要我配合
-
耦合现象二：明明有某个功能，却拿不出来
第一个现象就是变化多，在业务的某个阶段，有的领域的确比其他的领域有更多的变化，如果耦合在一起，上线，稳定性都会相互影响。例如图中，供应链越来越多，活动方式越来越多，物流越来越多，如果都耦合在Online里面，每对接一家物流公司，都会影响下单，那太恐怖了。
第二个现象就是可复用，例如用户中心和认证中心，根本整个公司应该只有一套。
在《重构：改善代码的既有设计》有一个三次法则——事不过三，三则重构。
这个原则也可以用作服务化上，也即当物流模块的负责人发现自己接到第三家物流公司的时候，应该就考虑要从Online中拆分出来了。另外就是，当有一个功能，领导或者业务方发现明明有，还需要再做一遍，这种现象出现第三次的时候，就应该拆分出来作为一个独立的服务了。
这种根据业务需求逐渐拆分的过程，会使得系统的修改一定是能够帮助到业务方的，同时系统处在一种可控的状态，随着工具链，流程、团队、员工能力的增强慢慢匹配到服务化的状态。
这个阶段服务化的结果如下图所示。
4.2、技术架构：基础设施云化，统一接口，抽象概念，租户自助
服务化的过程，工具链很重要，技术架构就是解决这个问题的。
经过业务层的的服务化，也对运维组造成了压力。
应用逐渐拆分，服务数量增多。随着服务的拆分，不同的业务开发组会接到不同的需求，并行开发功能增多，发布频繁，会造成测试环境，生产环境更加频繁的部署。而频繁的部署，就需要频繁创建和删除虚拟机。如果还是采用上面审批的模式，运维部就会成为瓶颈，要不就是影响开发进度，要不就是被各种部署累死。
这就需要进行运维模式的改变，也即基础设施层云化。
虚拟化到云化有什么不一样呢？云计算带来的改变，统一接口，抽象概念，租户自助。
首先是接口统一，例如基于OpenStack实现，大部分部署工具支持其接口，可基于开源工具实现发布的工具化和平台化。
其次是概念的抽象。
原来出现服务器机型碎片化，资源分配碎片化的现象。Flavor抽象资源配比（4G 8G 计算优化型，网络优化型，存储优化型），统一硬件配置，提升利用率，硬件上线效率提升。
VPC屏蔽物理网络复杂性，冲突问题和安全问题，使得租户可自行配置网络。原来的网络使用的都是物理网络，问题在于物理网络是所有部门共享的，没办法交给一个业务部门自由的配置和使用。因而要有VPC虚拟网络的概念，每个租户可以随意配置自己的子网，路由表，和外网的连接等，不同的租户的网段可以冲突，互不影响，租户可以根据自己的需要，随意的在界面上，用软件的方式做网络规划。
其三是租户自助。
