原文 https://www.jianshu.com/p/96801c93a47d
DDD是什麼？
領域驅動設計是一種處理高度複雜域的設計方法，試圖分離技術實現的複雜性，圍繞業務概念構建領域模型來控制業務的複雜性，以解決軟件難以理解，難以演化等問題。團隊應用它可以成功地開發複雜業務軟件系統，使系統在演進時任然保持敏捷。
另外一種解讀：DDD不是語言，不是框架，不是架構，而是一種思想，一種套路，它可以分離業務複雜度和技術複雜度，DDD也並不是一個新的事物，它是面向對象的拔高，最終目標還是
高內聚，底耦合
DDD主要解決的問題？
-
如何合理的劃分業務系統？
這爲微服務的劃分提供了方法論（微服務的粒度的問題，多大算大，多小又算小，在微服務剛興起時，很多企業或者架構師對它都沒有統一且明確的定義，這裏給些examples，e.g：代碼行數？職責的劃分？披薩原則？組織結構？）界限上下文很好的回答了這個問題，這也是DDD最近幾年借微服務的東風，火起來的原因之一(領域驅動設計的提出距今已經十多年，但真正火熱起來大約是在2013年微服務架構被提出來之後)。 -
如何保持業務架構和系統架構的一致性？
與傳統的系統相比，DDD裏面強調領域專家和技術團隊的合作，建立統一語言“普通話”， 聚焦在領域，領域邏輯和業務流程上面，使整體團隊對同一個業務術語有統一的認識，避免理解的偏差，並將這些“術語”映射到代碼中，隨着系統的演進變遷。
DDD戰略設計？
DDD領域劃分?
根據問題域，將問題劃分爲Core domain，Sub domain， Support subdomain和generic subdomian，大概標準如下：
- 核心域：核心競爭力，核心業務 (需要投入最好的人力和資源)
- 支持子域： 沒有，很糟糕; 有，也不足以脫穎而出(可以考慮外包)
- 通用子域：都有的東西, 比如認證, 發短信, 客服系統等(可以考慮購買商業解決方案或者採用開源方案)
DDD領域建模方法？
領域建模的方式很多種，比如四色建模、OOAD還有事件風暴，我們這裏只簡單聊聊如何使用事件風暴梳理業務流程，建立領域模型，劃分邊界。
DDD事件風暴四部曲？
- 識別領域事件
事件是對結果進行建模，我們在尋找領域事件時，首先需要明白領域事件具備的幾個特徵：
- 具有業務意義
- 過去時，e.g: "XX已XX"
- 時序性
事件風暴以過去發生的事件追溯系統的數據和行爲，從而進行合適的建模，e.g：
-
識別命令
命令可以理解爲不同角色用戶在界面上面的操作，比如“添加商品”，“編輯庫存”，“提交訂單”等； 有些命令可能產生多個事件，可以將他們用箭頭聯繫起來; 在進行這個過程中，我們也需要將角色，通過不同的顏色標示出來 e.g:
![]()
命令風暴.png -
尋找聚合
在DDD中，聚合是一組相關的領域對象，其目的是要確保業務規則在邊界內的不變性，聚合根具有全局標識，所有對聚合根內對象的修改，都只能通過聚合根進行，聚合幫助我們簡化了複雜的對象網絡，逐步做到“高內聚，低耦合”。
在識別聚合的時候，我們可以通過對命令和事件的劃分找到聚合邊界，識別出分佈在時間軸上面不同位置的相關命令和事件，e.g：
![]()
尋找聚合.png -
邊界劃分
劃分服務的邊界，它一定程度上面對應的是“界限上下文”，關於它有一個非常形象的定義：
細胞之所以會存在，是因爲細胞膜定義了什麼在細胞內，什麼在細胞外，並且確定了什麼物質可以通過細胞膜
一個聚合可能是最小顆粒度的界限上下文，同時，我們常合併業務相關性很高的聚合。e.g:
最後在領域劃分的時候，需要團隊一起對業務達成共識，首先建立統一語言，然後識別領域模型，劃分子域和界限上下文，在驗證界限上下文的時候，如果你發現有過多的角色在同一個子域或者界限上下文時，就需要注意了，這就是典型的壞味道，需要及時調整的訊號。
DDD與微服務
理想情況下，界限上下文與微服務可以一一對應，在實際項目中，有些調整，比如根據業務的相關度和變化頻率，有時候我們會將多個界限上下文進行合併；另外微服務在開發，測試，部署，發佈和運維等等時，相比單體應用而言，它面臨了所有分佈式系統面臨的問題，帶來了額外的複雜度和開銷，所以將微服務粒度拆分過細反而是一種反模式，需要考慮需要解決問題的複雜度，將相對簡單的服務合併在一起；在微服務拆分的時候，也要注意：“聚合是服務的最小單元”（一個界限上下文可以包括多個聚合），打破聚合，就很有可能破壞事務一致性和業務約束。
參考資料
作者：魔鏡的技術心經
鏈接：https://www.jianshu.com/p/96801c93a47d
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。