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

原文:

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

領域驅動設計（ddd）是一種基於模型驅動的軟體設計方式。它以領域為核心，分析領域中的問題，通過建立乙個領域模型來有效的解決領域中的核心的複雜問題。eric ivans為領域驅動設計提出了大量的最佳實踐和經驗技巧。只有對領域的不斷深入認識，才能得到乙個解決領域核心問題的領域模型。如果乙個應用的複雜性不是在技術方面的，而是在領域本身，即領域內的業務很複雜，那這種應用，使用領域驅動設計的價值就越大。

領域驅動開發也是一種敏捷開發過程（極限程式設計，xp），強調迭代開發。在迭代過程中，強調開發人員與領域專家需要保持密切的合作關係。極限程式設計假設我們能通過不斷快速重構完善設計。所以，對開發人員的要求非常高。

領域驅動設計提出了一套核心構造塊（building blocks，如聚合、實體、值物件、領域服務、領域工廠、倉儲、領域事件，等）,這些構造塊是對物件導向領域建模的一些核心最佳實踐的濃縮。這些構造塊可以使得我們的設計更加標準、有序。

統一語言（ubiquitous language），是領域驅動設計中乙個非常重要的概念。任何乙個領域驅動設計的專案，都需要一種通用語言，一套通用的詞彙。因為沒有通用的語言，就沒有一致的概念，溝通就會遇到障礙，最後的領域模型和軟體也就無法滿足領域內的真實業務需求。通用語言是領域專家和開發人員在對領域問題的溝通、需求的討論、開發計畫的制定、領域模型的設計，以及開發人員之間對領域模型的具體編碼落地實現，等一系列過程中，所有人員使用的一種通用語言。話句話說，就是無論是溝通時所用的詞彙、還是領域模型中的概念、還是****現的類名與方法，只要是相同的意思，那就應該使用相同的詞彙。可以看出，這種通用語言不是一下子就可以形成，而是在乙個各方人員討論的過程中，不斷發現、明確，與精煉出來的。

領域模型可以復用，因為特定的領域模型解決的都是某個特定的問題域；比如**網有個商品中心，有個商品模型，核心概念有商品分類、商品；商品模型負責解決電子商務領域中的商品目錄（product catalog）子域。後來阿里又出了個天貓，也會有商品中心，但是這兩個商品中心基本是一樣的問題域。所以，我們可以復用之前**實現的商品中心領域模型，並復用之前**商品中心的解決方案，來解決天貓的商品維護和展示。當然，這個只是我個人的認識，乙個例子。具體阿里是否是乙個商品中心同時解決**和天貓的業務，沒具體調研過。

bounded context，屬於一種軟體構件，作用是用來對領域模型進行劃分。bounded context有兩層含義：

領域建模的方法有很多種，我分享一下自己的一種基於場景為核心的分析方法。大概的思路是：

關於領域（domain）、領域模型（domain model）、邊界上下文（bounded context）的關係

關於domain、sub domain、core domain、generic domain，以及shared kernal的理解：

為什麼乙個大的領域模型需要劃分？因為，通常乙個大的領域模型需要多個團隊合作完成。如果多個團隊基於乙個共同的領域模型工作，由於每個團隊的關注點不同，且一些看似叫法一樣的概念，對於不同的團隊，其背後的意思完全不同。所以，這樣的概念含義模糊會給團隊以及成員之間的合作帶來很大的困擾。所以，我們需要通過一種手段（bounded context），將領域模型劃分為不同的部分，確保同乙個bounded context內的領域模型所表達的概念含義明確。然後，同乙個bounded context下面，相關人員都使用一種統一的語言，以此來保證團隊成員之間溝通能暢通無阻；

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

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

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

DDD領域驅動設計

相關推薦