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

通用域

高复用能力或者没有太多个性化需求的领域，比如所谓的“中台”概念就是指高复用的模块化服务，整合所有底层能力，快速迭代前台功能。

支撑域

支撑域是对核心域有所支持，但不是业务的核心竞争力的部分。这部分的业务规则相对简单，通常不需要深入理解业务需求，只需要满足基本的业务需求即可。
3、实体和值对象
什么是实体？在业务中有具有唯一标识的对象。比如在电商场景下，一个物品对象就可以是一个实体，物品有唯一标识符（物品 id），物品的业务表现可能会发生变化，但是标识符在整个业务周期中是保持一致，比如一个物品在购买前是商品、购买后就变成了需发货的货物、如果要起退款就变成了一个需要召回的物品，但始终物品的标识符不会改变。
什么是值对象？针对一个实体对象，光有一个唯一标识是不够的，它不足于描述对象的特性，所以就有了属性，比如一个商品的属性一般有名称、价格、图片、生产地，而值对象就是一个业务实体属性的集合。
在实践中，业务实体往往对应着一个实体类，这个实体类有唯一的标识、属性、以及其所有的业务方法。领域驱动提倡使用充血模型的方式，即在类中实现所有相关的业务方法，而不是只把数据直接对外暴漏，这样可以很好的保证了业务数据的一致性和封装的特性，以下是一个物品对象的类实现。
//实体
//物品类
public class Product{
private String productId; //唯一主键唯一标识
private String productName;
private String productUrl;
private String productPrice;
Private Address productAddress；// 属性集合
// get set 业务行为 ...
public function（）{}
}
//值对象
//仓库地址类（无主键id）
public class ProductAddress{
private String Province；
private String City；
private String District；
}
4、聚合和聚合根
当我们需要完成一个业务功能时，往往不是一个人就可以完成，而是大家协同工作，一起完成目标，在领域驱动中，实体就好像我们每一个人，聚合就是可以让我们协同工作的组织，聚合根就是这个组织的领导者，所以聚合其实就是由业务逻辑紧密关联的实体和值对象的集合，每个聚合有唯一的聚合根和业务边界，聚合一般会根据业务单一职责和高内聚原则设计，来确定其需要包括哪些业务实体以及值对象。
我们以购物车场景为例来体会一下聚合和聚合根的含义，在购物车中，加入购物车的商品列表构成了一个聚合，购物车 id 即聚合根，通过购物车 id，外界可以访问购买物品的列表信息、状态、下单总金额等。

文章插图
如果要用代码实现这个简单的场景，我们很自然地想到可以把购物车的相关逻辑实现在一个微服务里，实际上，在领域驱动中，一组相关的业务聚合往往通过一个微服务来实现。再初步了解领域驱动的相关概念后，我们梳理一下它们之间的关系，如图所示。

文章插图
三、拆分与合并
上一节我们已经讲解了一些领域驱动中一些重要的概念，这一节我们会介绍领域驱动中，关于分治与合并思想的落地，下面我们就分别讨论这两个过程。
1、拆分与微服务架构
我们还是回到归并排序的案例中，思考一下平时所写代码与归并排序的相似之处，我们简单的对归并排序代码做一些改造，如下：
void mergeSort(std::vector<int>& arr, int left, int right) {
//拆分过程
//把mergeSort(arr, left, mid)改写成
int resA=rpc.funtionA();
//把mergeSort(arr, mid + 1, right)改写成
int resB=rpc.funtionB();
//合并过程 merge(arr, left, mid, right)改为
func(resA,resB);
}
想想看，这不就是我们平常写的应用层代码吗，先远程同步调用 A 服务获取信息，再同步调用 B 服务，再组合所有结果数据进行运算并返回，如下图所示。

文章插图
这不就是微服务的分层架构嘛！领域驱动最后的落地实现形式就是微服务，到这里就可以回答上面提出的一个问题，为什么领域驱动的理念是02年提出了，但是到了15年后才被人熟知，就是因为云原生、微服务架构的发展是在15年左右，这给领域驱动的理念提供了一片可以生存的土壤；相反领域驱动也给微服务的设计提供了必要的方法论。