2. 程式人生 > >領域驅動設計（DDD）部分核心概念的個人理解

領域驅動設計（DDD）部分核心概念的個人理解

阿新 • • 發佈：2019-01-14
  1. 領域驅動設計（DDD）是一種基於模型驅動的軟體設計方式。它以領域為核心，分析領域中的問題，通過建立一個領域模型來有效的解決領域中的核心的複雜問題。Eric Ivans為領域驅動設計提出了大量的最佳實踐和經驗技巧。只有對領域的不斷深入認識，才能得到一個解決領域核心問題的領域模型。如果一個應用的複雜性不是在技術方面的，而是在領域本身，即領域內的業務很複雜，那這種應用，使用領域驅動設計的價值就越大。
  2. 領域驅動開發也是一種敏捷開發過程（極限程式設計，XP），強調迭代開發。在迭代過程中，強調開發人員與領域專家需要保持密切的合作關係。極限程式設計假設我們能通過不斷快速重構完善設計。所以，對開發人員的要求非常高。
  3. 領域驅動設計提出了一套核心構造塊（Building Blocks，如聚合、實體、值物件、領域服務、領域工廠、倉儲、領域事件，等）,這些構造塊是對面向物件領域建模的一些核心最佳實踐的濃縮。這些構造塊可以使得我們的設計更加標準、有序。
  4. 統一語言（Ubiquitous Language），是領域驅動設計中一個非常重要的概念。任何一個領域驅動設計的專案，都需要一種通用語言，一套通用的詞彙。因為沒有通用的語言，就沒有一致的概念，溝通就會遇到障礙，最後的領域模型和軟體也就無法滿足領域內的真實業務需求。通用語言是領域專家和開發人員在對領域問題的溝通、需求的討論、開發計劃的制定、領域模型的設計，以及開發人員之間對領域模型的具體編碼落地實現，等一系列過程中，所有人員使用的一種通用語言。話句話說，就是無論是溝通時所用的詞彙、還是領域模型中的概念、還是程式碼中出現的類名與方法，只要是相同的意思，那就應該使用相同的詞彙。可以看出，這種通用語言不是一下子就可以形成，而是在一個各方人員討論的過程中，不斷髮現、明確，與精煉出來的。
  5. 領域模型是領域驅動設計的核心。統一語言中的所有關鍵詞彙，在領域模型上應該都能找到。各方人員溝通時，都應該以領域模型為基礎。通過討論的不斷深入，大家對領域的認識也會不斷深入，領域模型也會不斷得到完善，統一語言的詞彙也會不斷豐富和精準。需要特別強調的是，開發人員應該儘量保證程式碼實現和領域模型相繫結，時刻保持程式碼與模型的一致。如果不繫結，那程式碼就會慢慢和模型相脫節，就會出現像我們以前那樣的設計文件和程式碼相脫節一樣的問題，甚至模型還會起到誤導作用。通過這樣一種思路，我們確保語言、模型、程式碼三者緊密繫結，確保最後實現出來的軟體可以準確無誤的實現業務需求，並且還能讓我們的軟體可以快速的和業務同時演進。而不像傳統的開發方式那樣，分析、設計、實現三個階段完全脫節，最後出來的軟體沒有很好的滿足業務需求，也不能在未來很快的跟業務需求一起演進。所以，領域模型同時承載了分析的結果和設計的結果，這裡的分析是指對領域內業務需求的分析，設計是指對模型的設計以及軟體的設計。所以，我們的領域模型，不能只考慮業務需求，還要同時考慮軟體設計的原則，是一種綜合考慮的、平衡的設計結果。
  6. 領域模型可以複用，因為特定的領域模型解決的都是某個特定的問題域；比如淘寶網有個商品中心，有個商品模型，核心概念有商品分類、商品；商品模型負責解決電子商務領域中的商品目錄（Product Catalog）子域。後來阿里又出了個天貓，也會有商品中心，但是這兩個商品中心基本是一樣的問題域。所以，我們可以複用之前淘寶實現的商品中心領域模型，並複用之前淘寶商品中心的解決方案，來解決天貓的商品維護和展示。當然，這個只是我個人的認識，一個例子。具體阿里是否是一個商品中心同時解決淘寶和天貓的業務，沒具體調研過。
  7. Bounded Context，屬於一種軟體構件，作用是用來對領域模型進行劃分。Bounded Context有兩層含義：
    • Bounded，即有邊界的，表示領域模型有邊界；這個邊界定義了模型的適用範圍，以便讓負責該模型的團隊知道什麼該在模型中實現，什麼不該；
    • Context，即領域模型的產生是在某個上下文中產生的；上下文是一個和環境相關的概念。比如一次頭腦風暴會議大家達成了一個模型，那這次會議的討論就是該模型的上下文；比如某本書中談到了某個東西，那這個東西的上下文就是那本書，那個東西要有意義的前提離不開那本書這個上下文；所以，上下文是模型有意義的前提；
  8. 領域建模的方法有很多種，我分享一下自己的一種基於場景為核心的分析方法。大概的思路是：
    • 通過與領域專家和業務需求人員溝通，找出領域中的關鍵業務場景；
    • 針對每個業務場景分析出有哪些場景參與者，哪些參與者以物件（聚合）的形式參與，哪些參與者以服務的形式參與；
    • 分析每個場景參與者物件的基本狀態特徵；
    • 分析每個場景參與者物件分別扮演什麼角色參與場景，整個場景的完整互動過程是怎樣的，物件在參與場景的過程中執行了哪些互動行為；
    • 分析如何記錄和跟蹤這一次互動行為，分析這次互動行為會產生哪些額外的資訊；
    • 上面，只是簡單列了一下條目，具體的描述，請參看我的另一篇文章，有詳細的敘述。
  9. 關於領域（Domain）、領域模型（Domain Model）、邊界上下文（Bounded Context）的關係
    • 領域就是問題域，問題空間；
    • 領域模型是一種模型，表達了領域中哪些業務需求以及業務規則必須被滿足；
    • 每一個領域中的問題，都會有一個對應的領域模型去解決；
    • Bounded Context的作用是用來對領域模型進行劃分；
    • 劃分領域就是對問題空間的劃分，通俗的理解，就是將大問題拆分為小問題；
    • 劃分Bounded Context就是將一個大的領域模型劃分為多個小的領域模型；
    • 可以把Bounded Context看成是一種解決方案空間，所以，Bounded Context也可以理解為是對解決方案空間的劃分；
    • 理論上，一個Domain可能會對應多個Bounded Context；同樣，一個Bounded Context可能也會對應多個Domain；所以他們之間沒有絕對的關係。主要是他們劃分的依據不同，一個是針對領域（問題空間），一個是針對領域模型（解決方案空間）；理想情況，一個Domain最好對應一個Bounded Context；
  10. 關於Domain、Sub Domain、Core Domain、Generic Domain，以及Shared Kernal的理解：
    • 一個領域（Domain）會拆分為多個子領域（Sub Domain）；
    • 子領域中最核心（最重要）的那個叫Core Domain；我們應該講團隊的核心資源用在核心子域上，因為它是產品成敗的關鍵；
    • 除了Core Domain外，其他的是支撐子域（Supporting Subdomain）；
    • 有些支撐子域比較特殊，因為它解決的是一類通用問題，比如賬號和許可權；這類子域我們叫做通用子域（Generic Subdomain）；通常，通用子域對應的Bounded Context，會跨域多個子域；
    • 多個子領域有時會有相交的部分，我們稱作共享核心（Shared Kernel）；體現到程式碼上，就是同一份程式碼，在兩個領域模型中複用；
    • 一般只有Domain比較大的時候，我們才會劃分出Sub Domain；
  11. 為什麼一個大的領域模型需要劃分？因為，通常一個大的領域模型需要多個團隊合作完成。如果多個團隊基於一個共同的領域模型工作，由於每個團隊的關注點不同，且一些看似叫法一樣的概念，對於不同的團隊，其背後的意思完全不同。所以，這樣的概念含義模糊會給團隊以及成員之間的合作帶來很大的困擾。所以，我們需要通過一種手段（Bounded Context），將領域模型劃分為不同的部分，確保同一個Bounded Context內的領域模型所表達的概念含義明確。然後，同一個Bounded Context下面，相關人員都使用一種統一的語言，以此來保證團隊成員之間溝通能暢通無阻；

相關推薦

領域驅動設計（DDD）部分核心概念的個人理解

領域驅動設計（DDD）是一種基於模型驅動的軟體設計方式。它以領域為核心，分析領域中的問題，通過建立一個領域模型來有效的解決領域中的核心的複雜問題。Eric Ivans為領域驅動設計提出了大量的最佳實踐和經驗技巧。只有對領域的不斷深入認識，才能得到一個解決領域核心問題的領域模型。如果一個應用的複雜性不是在技

領域驅動設計（DDD）- 請先搞清楚一些概念

責任 可能 升級 是你 ora ext 計數 方法 避免 開發一個新系統 　　一般我們開始開發一個商業系統都需要做什麽？讀需求文檔去查找功能點，拆解任務。多數情況下，拆解項目是為了評估工作，做評估、分配任務到個人、設計數據庫結構，然後就開始了Coding。 所以，這種方

領域驅動設計（DDD）在美團點評業務系統的實踐

點選上方藍字訂閱，不錯過下一篇好文章本文轉自美團點評技術公眾號：meituantech前言至少3

關於領域驅動設計（DDD）中聚合設計的一些思考

關於DDD的理論知識總結，可參考這篇文章。 DDD社群官網上一篇關於聚合設計的幾個原則的簡單討論： 聚合是用來封裝真正的不變性，而不是簡單的將物件組合在一起； 聚合應儘量設計的小； 聚合之間的關聯通過ID，而不是物件引用； 聚合內強一致性，聚合之間最終一致性； 上面這幾條原則，作者通過

解構領域驅動設計（二）：領域驅動設計的核心之分層架構

() shc created win cif nec upd 方法 bool 反映業務規則的代碼是整個軟件的核心，但是它一般只占很小的一部分，在傳統的基於貧血模型的分層軟件架構中，業務規則可能分散到各個層、各個代碼段，從而使得通過代碼來還原業務規則或者保證代碼與業務規則一致

解構領域驅動設計（一）：為什麼領域驅動設計能夠解決軟體複雜性

1 為什麼我要研究領域驅動設計 1.1 設計方法各樣且程式碼無法反映設計 我大概從2017年10月份開始研究DDD，當時在一家物流資訊化的公司任職架構師，研究DDD的初衷在於為團隊尋找一種軟體設計的方法論。作為架構師，經常參與設計評審，包括：需求評審、設計評審、程式碼評審。在評審過程中，有一點感受非常深，

解構領域驅動設計（一）：為什麽領域驅動設計能夠解決軟件復雜性

unp 問題 困難 技術 工作 質量管理 exce urn 如果 1 為什麽我要研究領域驅動設計 1.1 設計方法各樣且代碼無法反映設計 我大概從2017年10月份開始研究DDD，當時在一家物流信息化的公司任職架構師，研究DDD的初衷在於為團隊尋找一種軟件設計的方法論。

領域驅動設計（一）

領域驅動 問題 圖片 info wid http 空間 ima alt 問題空間 領域驅動設計（一）

解構領域驅動設計（三）：領域驅動設計

ddd 引擎 .get states 成員變量 float 類的屬性 table custom 在上一部分，分層架構的目的是為了將業務規則剝離出來在單獨的領域層中進行實現。再回顧一下領域驅動設計的分層中應用層代碼的實現。 @Override public void

從零開始使用CodeArt實踐最佳領域驅動開發（五）

using emp 程序集 mman his return main 更新 物理 本章內容還在整理上傳中，你可以等全部更新完畢後再查閱也可以先預覽已上傳的內容。。。。。。 7. 應用層的命令模式 　　在上個章節裏我們設計並編碼了領域對象Permission，但是目前Perm

.NET領域驅動設計—看DDD是如何運用設計模式顛覆傳統架構

閱讀目錄： 1.開篇介紹 2.簡單瞭解緣由（本文的前期事宜） 3.DomainModel擴充套件性（運用設計模式設計模型變化點） 3.1.模型擴充套件性 3.2.設計模式的使用（苦心專研的設計模式、設計思想可以隨意使用了） 3.3.部分類的使用（封裝內部物件） 3.4.高強度的OO設計（

Drools 規則引擎----向領域驅動進步（一）

PS:文章還在寫，目前都是一些概念性質的，想要做拓展的程式猿請過幾天再看，Drools會一致做完的~~~ 1. 工欲善其事，必先利其器 Drools提供基於eclipse的IDE(這是可選的)，但其核心只需要Java 1.5(Java SE)。

Drools 規則引擎----向領域驅動進步（四）

1.複雜事件處理 到目前為止，我們已經看到如何使用規則，以基於資料（我們稱呼它為fact）來做出決定。這個資訊幾乎是任何一組Java物件，它們描述了我們正在做決策的域的狀態，但是它總是在一個特定的時間點上代表這個世界的狀態。本章我們將會去看一些列的概念，配置和

ios多線程操作（四）—— GCD核心概念

indent img 操作 fort 16px 2.0 b2c 有一種 read GCD全稱Grand Central Dispatch。可譯為“大派發中樞調度器”，以純C語言寫成，提供了很多很強大的函數。GCD是蘋果公司為多核的並行運算提出的解決方式，它能夠自己主

kafka（三）：核心概念以及框架

一、核心概念 1.Message： 資料.傳遞的資料物件，主要由四部分構成：offset(偏移量)、key、value、timestamp(插入時間)。 2.Broker： 一般情況一臺伺服器一個broker，但是可以部署多個,反應到具體的程序就是Kafka程序 3.Topic：

《Hadoop Yarn權威指南》學習筆記（零）——Yarn核心概念

本文是我讀《Hadoop Yarn權威指南》的筆記，文字部分是書上的內容摘錄，如有誤歡迎指出 yarn的架構圖如下 1 ResourceManager 為系統中所有應用分配資源。 有一個可插拔的排程器Scheduler，負責為執行中的各種應用分配資源，使用一個叫Con

Elasticsearch學習（二）Elasticsearch核心概念

核心概念 （1）Near Realtime（NRT）：近實時，兩個意思，從寫入資料到資料可以被搜尋到有一個小延遲（大概1秒）；基於es執行搜尋和分析可以達到秒級 （2）Cluster：叢集，包含多個節點，每個節點屬於哪個叢集是通過一個配置（叢集名稱，預設是elasticsearc

Dubbo（二）--dubbo核心概念

一、簡介 Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高效能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向介面的遠端方法呼叫，智慧容錯和負載均衡，以及服務自動註冊和發現。 官網：http://dubbo.apache.org/

Storm學習筆記（2）- Storm核心概念

文章目錄 Storm核心概念理解記憶之地鐵執行模型 Storm核心概念理解記憶之Storm Storm核心概念總結 官方連結： http://storm.apache.org/releases/1.2.2/Co

MVVM架構模式 入門（三）MVVM核心概念

轉：https://www.cnblogs.com/iammackong/articles/3312565.html MVVM核心概念 MVVM模式是Model、View、ViewModel的簡稱，最早出現在WPF，現在Silverlight中也使用該模式，MVVM模式是對MVC模式的變種。