中台过气、微服务回归单体，DDD的意义何在？( 二 )_DDD

int mid = left + (right - left) / 2;
//拆分过程一拆二
mergeSort(arr, left, mid); //子函数1
mergeSort(arr, mid + 1, right);//子函数2
//合并过程
merge(arr, left, mid, right);
}
//合并函数
void merge(std::vector<int>& arr, int left, int mid, int right) {
//实现
}
而领域驱动在实现的过程中依旧沿用了这个思路即：定义问题、分解问题、合并结果。
定义问题：当我们面对一个复杂场景时，首先需要确定面对的问题是什么？问题的边界（限界上下文）在哪里，我们很容易理解解决问题带来的价值，但是很容易忽略定义问题带来的价值。在项目实践中，不知道你有没有遇到过这样的一种场景：技术同学会根据产品同学的一段描述立马会陷入到技术实现中，等到验收的过程中才会说出：“哦，原来你只需要实现这种需求呀”的感叹，这就是没有找到核心问题所在。
分解问题：定义好问题即明确了问题的边界，我们就可以在边界内进行问题的划分，领域驱动的核心思想是分治，即拆分“边界分明”的子问题，再针对子问题进行解决。这里分解问题的思路，也和微服务拆分的思路有异曲同工之秒（说到微服务这里抛出两个有趣的问题，第一：领域驱动是03年就提出来了的概念，为什么一直到15年左右才渐渐被大家熟知；第二：微服务和领域驱动有什么关系，我相信在读完本文后，你心中自有答案）
合并结果：解决完一个一个的子问题还不够，如何把信息串起来才是难点，在串起来的过程中就会出现耦合问题，这就又回到了一个软件实践中一个普遍的问题：如何做到“高内聚、低耦合”，其实细心的小伙伴已经发现了，这里的分解问题的目标就对应着高内聚，而合并结果的目标则是低耦合。
二、那些晦涩难懂的术语
上一节我们讲解了领域驱动所想解决的问题：降低系统复杂度，以及它解决问题的思路：统一语言、模型抽象、分而治之。明确了这两点，我们再去看看其中的一些抽象的概念，相信你会有更深的理解。
1、在边界内做事：领域与子域
概念上领域指：从事一种专门活动或者事业的范围，这里的重点在于范围两个字，范围即边界。不管我们去解决什么问题，问题总是有边界的，边界越清晰，解决问题的思路则越清晰，再简单点说，领域就是在一个边界内要解决的问题。针对一个复杂问题，使用分治的思想，还可以进一步拆分成子问题。这种研究问题的思路其实已经司空见惯，假如我们需要研究人体，那么人即问题的研究对象，我们可以按照不同的方法把把问题拆分成子问题，以下是两个不同的思路，左图是按照“系统” 划分，右图是按照“组成”划分。

文章插图
如何分解，没有所谓的标准答案，拆分的方式不同，其实也可以说是抽象的角度的不同，因为抽象的角度不同，研究的方法也会有不同。比如中医研究人体会侧重于整体和部分的关系，西医则侧重于定量分析，我们不能说那种好或者不好，只是看待问题的角度不同，角度即抽象。
【中台过气、微服务回归单体，DDD的意义何在？】当完成分解过程，我们在针对子问题，再寻求对应的解决思路，这个过程就是从问题域到解决域的过程，以下图可以更直接的帮助你理解。

文章插图
2、领域按功能再划分：核心域、通用域、支持域
在不断划分的过程中，还可以按照功能性的不同把子领域再次的化为：核心域、通用域、支持域，这里需要强调的是子域的划分完全建立在对于业务的理解之上，基于业务，而非技术。

核心域

是指富有竞争力的领域，这里是仁者见仁、智者见智，不同的人对于竞争力有着不同的理解，比如还是拿人来举例，身体、认知、财富到底哪一个是一个人的核心的竞争力，当认为是身体是核心的人就会侧重于锻炼健身；认为认知是核心的人则会侧重于看书学习；认为财富重要的人则会侧重于事业.... 总体看并不能说谁对谁错，这是看待问题的方式不同。
而对于公司也是一样的道理，我们看很多公司的业务和产品，表面上很相似，但是其实有着完全不同的商业模式，就以电商平台举例，有的核心领域在物流服务、高端的品质；有的核心领域则是更加便宜好用的货物上，对于一个公司来说，划定了一个核心领域，其实也就确定了资源投入的方向，把好钢用在刀刃上，提供差异化的价值服务。