1、起源及階段

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

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

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

??????????????????????????? 3、微服務架構(gòu)提出階段。

?2、何為DDD？

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

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

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

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

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

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

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

??????? 面向?qū)ο蠓治龊驮O計：基于對象，直接面對的是對象而不是數(shù)據(jù)表、不是ER數(shù)據(jù)模型。

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

4、DDD應用場景

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

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

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

??????? 3、業(yè)務問題基本轉(zhuǎn)化為數(shù)據(jù)表結(jié)構(gòu)來實現(xiàn)的也就是通過純數(shù)據(jù)結(jié)構(gòu)完成，這樣的系統(tǒng)如果再使用DDD重構(gòu)比較難，業(yè)務規(guī)則、模型核心都體現(xiàn)在數(shù)據(jù)表結(jié)構(gòu)中，即使這些表結(jié)構(gòu)設計不合理，考慮大量歷史遺留數(shù)據(jù)，也很難進行范式轉(zhuǎn)換。

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

????? 適合場景：

???????????? SOA服務和微服務架構(gòu)的軟件。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。