文章很長，且持續更新，建議收藏起來，慢慢讀！瘋狂創客圈總目錄博客園版 爲您奉上珍貴的學習資源：

免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ，幫你實現技術自由，完成職業升級，薪酬猛漲！加尼恩免費領
免費贈送經典圖書:《Java高併發核心編程（卷1）加強版》 面試必備 + 大廠必備 +漲薪必備加尼恩免費領
免費贈送經典圖書:《Java高併發核心編程（卷2）加強版》 面試必備 + 大廠必備 +漲薪必備加尼恩免費領
免費贈送經典圖書:《Java高併發核心編程（卷3）加強版》 面試必備 + 大廠必備 +漲薪必備加尼恩免費領

免費贈送資源寶庫： Java 必備百度網盤資源大合集價值>10000元加尼恩領取

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的分析具有很大的相似性，

在一些極爲簡單的業務系統、業務場景中，二者可以做簡單的映射：