其中服务为其核心竞争能力，包括该企业对全球各国的政策理解，即法律流程，服务资料（问卷），计算服务，资料审计服务，相比其他竞争对手的服务（价位/效率等），这些都为改企业提供核心的业务价值，自然也是核心子域。而其他用于统计改企业员工工作的工单，组织结构和员工为支撑子域，并不直接产生业务价值

　　领域划分的原则

　　在划分的过程中，经常纠结的一个问题是：这个模型（概念或数据）看起来放这个领域合适，放另一个也合适，如何抉择呢？

第一，依据该模型与边界内其他模型或角色关系的紧密程度。比如，是否当该模型变化时，其他模型也需要进行变化；该数据是否通常由当前上下文中的角色在当前活动范围内使用。

第二，服务边界内的业务能力职责应单一，不是完成同一业务能力的模型不放在同一个上下文中。

第三，划分的子域和服务需满足正交原则。领域名字代表的自然语言上下文保持互相独立。

第四，读写分离的原则。例如报表需有单独报表子域。核心子域的划分更多基于来自业务价值的产生方，而非不产生价值的报表系统。

第五，模型在很多业务操作中同时被修改和更新。

第六，组织中业务部分的划分也是一种参考，一个业务部门的存在往往有其独特的业务价值。

　　简单打个比方，同一个领域上下文中的模型要保持近亲关系，五福以内，同一血统（业务）。

　　领域划分的误区和建议

业务能力还是计算能力？在划分一些貌似通用的领域时，开奖，其实只是用到了通用的计算能力而不是业务能力，只需采用通用库的方式进行封装，而无需使用服务的方式。如我们系统的模板服务，是构建通用的模板服务，服务于整个平台的服务；还是每个服务拥有独立的模板模块？

尽早识别剥离通用领域。如身份认证与鉴权领域，是企业系统中最复杂、有相对多变的领域，需要及早隔离它对核心业务的干扰。

时刻促成技术人员与客户、业务人员的对话。业务领域的划分离不开对业务意图的真正理解。而需求人员和体验设计师对于User Journey的使用更熟悉，而技术人员、架构师对领域驱动设计、Eventstorming更熟悉。不管哪种方法都要求跨角色的群体协同工作，即客户人员、业务分析师、体验设计师与技术人员、架构师。而现实的情况中，User Journey更多的在Inception，在需求阶段进行，而领域驱动设计、Eventstorming更多的在开发设计阶段被使用，故而需求阶段经常缺失技术人员，而开发设计阶段经常缺失客户、业务人员的参与。

　　另一个常见的现象是，Inception的参与人员和真正的开发团队有可能不是同一个群体，那么Inception中的业务沟通往往以UI的方式作为传递，因此在开发中经常只能通过UI设计来理解业务的真正意图。

　　所以要想将正确的理解业务，做对软件，需要时刻促成技术人员与客户、业务人员的对话。

　　识别了被拆对象的结构和边界，下一步需要决定拆分的策略和拆分的步骤。

　　2.拆分方法与策略

　　拆分方法需要根据遗留系统的状态，通常分为绞杀者与修缮者两种模式。

绞杀者模式

　　指在遗留系统外围，将新功能用新的方式构建为新的服务。随着时间的推移，新的服务逐渐“绞杀”老的一流系统。对于那些老旧庞大难以更改的遗留系统，推荐采用绞杀者模式。

修缮者模式

　　就如修房或修路一样，将老旧待修缮的部分进行隔离，用新的方式对其进行单独修复。修复的同时，需保证与其他部分仍能协同功能。

　　我们过去所做的拆分中多为修缮者模式，其基本原理来自Martin Fowler的的重构方法，如下图所示：

　　就如我们团队所总结的16字重构箴言，我觉得十分的贴切：

　　“旧的不变，新的创建，一步切换，旧的再见”。

　　通过识别内部的被拆模块，对其增加接口层，将旧的引用改为新接口调用；随后将接口封装为API，并将对接口的引用改为本地API调用；最后将新服务部署为新进程，调用改为真正的服务API调用。

　　同时，拆分建议从业务相对独立、耦合度最小的地方开始。待团队获取相应经验和基础设施平台构建完善后，再进行核心应用迁移和大规模的改造。另外，核心通用服务尽量先行，如身份认证服务。

　　3. 拆分步骤