DDD中领域划分经验总结

IT公司在利用DDD进行开发时经常会出现扯皮的情景，例如：某个子功能，或者某个“跨多个领域”的业务服务如何提供时，就会产生开发人员相互踢皮球的情况。这里说一下领域服务划分的主要原则与处理技巧

1、邀请业务专家参与。业务专家对业务理解是最深刻的，你可以与业务专家一起，共同熟悉业务流程、业务关键活动。对业务有全面与深入的了解后，也需你就知道这个职责该交给谁了

2、数据专家原则。某个领域服务肯定会以来数据，核心或者主要数据属于哪个业务实体，业务实体属于哪个Domain，你就可以判断该服务所属于的业务领域了。也需会有一些辅助数据需要另外的业务域来提供，这个时候可以要求其提供一个查询数据的子服务，这样你就把一个外部领域服务成功拆解成多个服务了，并且核心数据域服务承担服务编排与组合的原则。

3、反向思考，原有的业务域是否划分的合理。职责划分讲究高内聚低耦合，原有的领域是否做到了这一点。

例如：A公司每个财年都会进行年终考核，基于考核结果直接调薪与分配年终奖，此时会冻结一份“员工汇报关系”（也就是主数据在某个时间点的快照），该汇报关系决定了“绩效考核关系”，即OD域；也决定了“奖金分配的审批流程”，即CB域。OD域与CB域都依赖“冻结的员工汇报关系”。 “冻结的员工汇报关系”无论放在OD域，还是放在CB域都有问题， 导致OD域与CB域经常扯皮。“冻结的员工汇报关系”属于主数据（MD），应该考虑单独独立成一个域，为OD域或CB域提供服务。

4、该服务如果不提供，谁最痛，谁要为此担责。 问责下去，必然会有相关人员收到惩罚。被惩罚者就是服务提供者。

5、还有其他吗？  领域划分本质是职责的划分。某个开发/开发组既然承担职责了，是不是相关的数据、权利都到位了呢？