DDD面试题：DDD聚合和表的对应关系是什么？（来自蚂蚁面试）-阿里云开发者社区

尼恩说在前面：

在40岁老架构师尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如字节、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

DDD 的外部接口调用，应该放在哪一层？

DDD架构，如何落地？

谈谈你的DDD落地经验？

谈谈你对DDD的理解？

如何保证RPC代码不会腐烂，升级能力强?

微服务如何拆分？

微服务爆炸，如何解决？

你们的项目，DDD是怎么落地实操的？

所以，这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典PDF》V155版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

除了本文，尼恩输出了一个《DDD学习圣经》系列，帮助大家彻底掌握DDD。

同时，尼恩持续输出最新的《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，后台回复：领电子书

蚂蚁面试真题：说说，DDD聚合和MYSQL表的对应关系是什么？

这是尼恩社群，一个小伙伴面蚂蚁，遇到的。

他没有回答好，这里个大家做个系统化、体系化、结构化的梳理

首先，说说什么是聚合？

“聚合”即“高内聚，低耦合”中的“内聚”之意；

聚合是业务和逻辑紧密关联的实体和值对象组合而成，聚合是数据修改和持久化的基本单元，一个聚合对应一个数据的持久化；

聚合在DDD分层架构中属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑，聚合内的实体以充血模型实现个体业务能力，以及业务逻辑的高内聚；跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现；

首先我们来看下聚合模式的定义:

将实体和值对象划分为聚合并围绕着聚合定义边界。

选择一个实体作为每个聚合的根，并仅允许外部对象持有对聚合根的引用。作为一个整体来定义聚合的属性和不变量，并把其执行责任赋予聚合根或指定的框架机制。

一个聚合包含一个聚合根（aggregation root）和一些相关的其他领域对象。

然后，说说，什么是聚合根？

在《DDD学习圣经》中，我们讲到了“什么是聚合根”，这里再重复一下。

聚合根中的“聚合”即“高内聚，低耦合”中的“内聚”之意；

而“根”则是“根部”的意思，也即聚合根是一种统领式的存在。

事实上，并不存在一个教科书式的对聚合根的理论定义，你可以将聚合根理解为一个系统中最重要最显著的那些名词，这些名词是其所在的软件系统之所以存在的原因。

为了给你一个直观的理解，以下是几个聚合根的例子：

在一个电商系统中，一个订单（Order）对象表示一个聚合根
在一个CRM系统中，一个客户（Customer）对象表示一个聚合根
在一个银行系统中，一次交易（Transaction）对象表示一个聚合根

你可能会问，软件中的概念已经很多了，为什么还要搞出个聚合根的概念？

我们认为这里至少有2点原因：

聚合根遵循了软件中“高内聚，低耦合”的基本原则
聚合根体现了一种模块化的原则，模块化思想是被各个行业所证明的可以降低系统复杂度的一种思想。所谓的DDD是“软件核心复杂性应对之道”，也即这个意思，它将软件系统在人脑中所呈现地更加有序和简单，让人可以更好地理解和管控软件系统。

在实际项目中识别聚合根时，我们需要对业务有深入的了解，因为只有这样你才知道到底哪些业务逻辑是内聚在一起的。

这也是我们一直建议程序员和架构师们不要一味地埋头于技术而要多关注业务的原因。

事实上，如果让一个从来没有接触过DDD的人来建模，十有八九也能设计出上面的订单、客户和交易对象出来。

没错，DDD绝非什么颠覆式的发明，依然只是在前人基础上的一种进步而已，这种进步更多的体现在一些设计原则上，对此我们将在下文进行详细阐述。

最后，说说Domain聚合和MYSQL数据表的对应关系是什么

Domain 聚合属于领域建模

MYSQL 数据表设计属于 DB建模

注意，从理论上来说， DB建模(数据表建模)和领域建模没有关系，二者在处于不同的设计阶段：

领域建模处于概要设计阶段，理清楚业务的内外边界，业务的内外流程，成果物为 HLD 概要设计文档。
DB建模处于详细设计阶段，理清楚业务的“关系数据模型”进而推导出“物理数据模型”，成果物为 LLD 详细设计文档。

具体如下图

在这里插入图片描述

DDD建模的四个标准动作，具体请参见尼恩《DDD学习圣经》以及配套视频。

数据建模的经典方法就是 E-R Model建模，而当我们做MYSQL E-R建模的时候，我们需要考虑：

需要建什么主表 - 可以类比为对象（当然也有些表只是为了关系映射）
表里面需要什么列 - 可以类比为这对象所需的属性
需要什么关联 - 表现数据对象与数据对象之间的联系

当然，E-R Model是数据模型的一种表现形式(数据建模不只是E-R Model一种表现形式) ，E-R Model以数据为中心，关注的是对象的实体和关系，建模时并不考虑Entity的行为。

在E-R概念模型的基础上可以建立“关系数据模型”进而推导出“物理数据模型”，这是一条以E-R Model为起始的数据建模的路线

ER模型分为实体、属性、关系三个核心部分。实体是长方形体现，而属性则是椭圆形，关系为菱形。
ER模型的实体（entity）即数据模型中的数据对象，例如人、学生、音乐都可以作为一个数据对象，用长方体来表示，每个实体都有自己的实体成员（entity member）或者说实体对象（entity instance），例如学生实体里包括张三、李四等，实体成员（entity member）/实体实例（entity instance）不需要出现在ER图中。

ER模型的属性（attribute）即数据对象所具有的属性，例如学生具有姓名、学号、年级等属性，用椭圆形表示，属性分为唯一属性（ unique attribute）和非唯一属性，唯一属性指的是唯一可用来标识该实体实例或者成员的属性，用下划线表示，一般来讲实体都至少有一个唯一属性。

ER模型的关系（relationship）用来表现数据对象与数据对象之间的联系，例如学生的实体和成绩表的实体之间有一定的联系，每个学生都有自己的成绩表，这就是一种关系，关系用菱形来表示。
ER模型中关联关系有三种：

1对1（1:1）：1对1关系是指对于实体集A与实体集B，A中的每一个实体至多与B中一个实体有关系；反之，在实体集B中的每个实体至多与实体集A中一个实体有关系。
1对多（1:N）：1对多关系是指实体集A与实体集B中至少有N(N>0)个实体有关系；并且实体集B中每一个实体至多与实体集A中一个实体有关系。
多对多（M:N）：多对多关系是指实体集A中的每一个实体与实体集B中至少有M(M>0)个实体有关系，并且实体集B中的每一个实体与实体集A中的至少N（N>0）个实体有关系。

在数据建模中通常将E-R Model就称之为概念数据模型，接下来的层面是关系数据模型和物理数据模型；

而Domain 建模是属于对象建模、业务建模的范畴，Domain 聚合和MYSQL 数据表二的区别是职责不同， ER建模关心数据如何存储，Domain 对象建模需要为对象建立职责（对象的行为）。

当然Domain 建模和E-R Model的分析具有很大的相似性，

在一些极为简单的业务系统、业务场景中，二者可以做简单的映射：