1、起源及階段

???? 2003年由Eric Evans完成了《Domain-Driver Design Tacking Complexity in the Heart of Software》一書開始，DDD進入大眾視野。

??? 主要3個階段：1、Eric Evans的理論原則創建和普及階段；

??????????????????????????? 2、引入領域事件、事件溯源階段；

??????????????????????????? 3、微服務架構提出階段。

?2、何為DDD？

?????? DDD將分析和設計結合起來，通過上下文的特殊性，將項目的真正業務背景和繼承復雜性引入設計建模階段，雖然增加了設計復雜性，但也提高了設計的實用性。

?????? DDD分析方法核心：從細節動詞入手發現有界上下文和聚合，以邏輯一致性為邊界劃分依據，對動作實現分門別類的畫法。

3、為什么會有DDD需求？為什么DDD逐漸風生水起？ ???

?????? 其根本原因需要放在一個更大的上下文（或背景）中去尋找，這個上下文就是軟件質量。

?????? 技術負債： 按照Martin Fowler的定義就是增加新功能所需的額外成本。技術負債是導致軟件質量下降的重要原因。

?????? 降低技術負債的解決辦法一種是適度問題，即適度的單一設計原則和DRY（不要重復自己）原則。另一種是引入架構元素，將各個環節串通，例如編碼完后增加單元測試和集成測試，盡可能將測試、發布和運維自動化實現DevOps哲學化管理。

?????? ER數據建模雖然也有一套分析設計方法論，但是由于過于注重數據庫技術而忽視了業務上下文。例如創建訂單替代“下單”。通過CRUD通用詞替代業務術語，最大的遺憾就是丟失業務上下文以后，設計的邏輯性將很難去追溯和質疑。

??????? 面向對象分析和設計：基于對象，直接面對的是對象而不是數據表、不是ER數據模型。

??????? 業務領域中業務對象是定義業務行為的一種結構；數據表模式是定義業務數據的結構。他們一個重業務行為，另一個重視業務的數據。不同的設計要求才有對象和數據結構兩種不同實現方式。跟跟那個精確放映領域概念，保證業務規則真正邏輯一致地實現，是面向對象分析和設計（OOAD）的主要有點。但是，傳統面向對象分析和設計也有問題，如分析和設計之間落差很大，甚至分裂。正是這一背景下，人們期待一中心的分析設計方法問世，它應比ER數據建模更加面向業務，能夠彌補OOA和OOD之間的天然裂縫，于是DDD來了。

4、DDD應用場景

????? 不適合應用DDD的場景：?

?????? 1、傳統的CRUD系統不適合使用DDD。因為大部分是簡單系統

??????? 2、小型系統或教學案例系統也不適合使用DDD。通常都是具體技術的使用和業務無關。

??????? 3、業務問題基本轉化為數據表結構來實現的也就是通過純數據結構完成，這樣的系統如果再使用DDD重構比較難，業務規則、模型核心都體現在數據表結構中，即使這些表結構設計不合理，考慮大量歷史遺留數據，也很難進行范式轉換。

??????? 4、如果是第一版系統1.0版時間緊任務重只是讓軟件運行起來，摸索的初步影響和結果，可以在后期需求方向漸漸確定后再迭代版本時將DDD應用上。

????? 適合場景：

???????????? SOA服務和微服務架構的軟件。

總結

以上是生活随笔為你收集整理的DDD领域驱动设计简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。