DDD戰略設計相關核心概念的理解

前言

本文想再討論一下關於領域、業務、業務模型、解決方案、BC、領域模型、微服務這些概念的含義和關係。初衷是我發現如今DDD領域建模以及解決方案落地過程當中，經常對這些概念理解不清楚或者有歧義，致使咱們不知道如何運用這些概念來落地咱們的軟件。先經過一個圖來講明一下這些概念之間的關係，以下圖所示

領域、業務、業務模型

• 領域，即問題域、問題空間，領域是一種邊界、範圍。因此，一個領域表明了一個問題域的邊界，也能夠理解爲是一個業務的邊界。領域邊界越大，業務範圍就越大，反之則相反；一般咱們你們交流都比較喜歡用業務這一詞，好比這塊業務，那塊業務，業務的邊界，我是一個業務開發人員（區分於我是一箇中間件開發人員）。而領域一詞，相對比較抽象，不是那麼容易懂。
• 領域既然是一個邊界，因此能夠劃分領域的大小，即領域劃分，劃分出來的子領域簡稱子域，每一個子域對應一個小的問題域和和小的業務；固然，不一樣的子域的重要性也是不一樣的，因此纔有了核心子域、支撐子域的說法，這點顯而易見。
• 每一個業務都有一個對應的業務模型（注意這個業務模型不是領域模型，而是一個業務概念的模型，領域模型下面會提到），這個業務模型設計的時候，徹底不須要考慮任何軟件設計的思想，好比對象的抽象、繼承、存儲、性能，等。咱們是從業務自己出發，分析業務邊界範圍內的各類業務概念，以及業務概念之間的關係，一般咱們可使用一個業務模型的圖來表達這些業務概念以及業務概念之間的關係。那麼如何獲得一個業務模型呢？最多見的有名詞動詞形容詞分析法，還有好比四色原型分析法，均可以。找一個適合本身的就行；業務模型自己很是有價值，它提煉了領域內業務的核心概念及其關係，能夠幫助咱們更好的理解業務自己。

解決方案

• 什麼是解決方案？咱們在進行DDD領域驅動設計的實踐時，會進行需求分析、領域劃分、領域建模等工做。而咱們的系統要落地，則須要有一套解決方案。例如，咱們要實現一個電商平臺，須要一個複雜的系統解決方案，可是若是這個解決方案過大，各模塊、組件都揉在一塊兒，那麼就不利於整個系統的維護、演進、伸縮，等。因此，咱們須要把解決方案拆分爲一個個獨立的小的解決方案；因此，咱們能夠發現，領域和解決方案，是兩個徹底不一樣的概念，領域表明問題空間，解決方案表明解決方案空間。
• 解決方案該如何拆分呢？簡單的回答是：看狀況，憑經驗。說的具體點，就是咱們須要使用軟件設計的各類原則、最佳實踐、設計模式、非功能特性的需求，以及團隊成員的狀況來指導咱們進行解決方案的拆分或者直接不拆分，最終得出一個綜合考慮後的拆分結果。因此，咱們發現解決方案的拆分的維度可能有不少，沒有一個單一的在任何狀況下都合理的切分維度。有時咱們可能從性能的角度來拆分，有時從不一樣架構分開演進（如CQRS架構）的角度，有時從分開伸縮的角度，有時從切合團隊組織架構的維度。可是拆分的時候，多考慮一些各個因素，才能讓咱們更好的進行解決方案空間的拆分。

BC

• BC，即Bounded Context，中文翻譯爲限界上下文。BC在DDD一書中首次出現，BC的理解分爲兩個層面：1）Bounded，表示邊界的意思；2）Context，即上下文，我理解爲是一個場景的上下文，這個場景不侷限於普通的業務場景，而是各類上下文都涵蓋在內，是一個時空感知的概念。好比咱們兩我的在公司交談時的上下文是一個上下文，可是在路上交談時，則切換到另外一個上下文了，由於交談的地點發生了變化；因此，BC合起來理解，就是一個上下文的邊界。
• BC有什麼用呢？就是爲了表達上面介紹的某個粒度的解決方案的上下文邊界。那爲什麼要強調這個邊界呢？有了這個邊界，咱們才能夠定義這個邊界內的領域模型中全部對象概念的明確含義。若是沒有這個上下文邊界，對同一律念在不一樣上下文的理解，你們就會產生誤差。舉個栗子：商品，在商品中心的解決方案BC中，商品中心負責管理電商平臺的全部商品，因此商品在商品中心BC中，是一個聚合根；可是在訂單中心解決方案BC中，雖然也叫商品，可是它只是一個值對象。咱們知道訂單中心的訂單是一個聚合，訂單內聚合了多條訂單明細，每一個明細是一個實體，每一個訂單明細對應了一個商品。雖然叫作商品，可是這個商品本質上只是商品中心的商品的一部分信息，如商品ID、標題、價格，且是隻讀的。甚至更爲常見的，叫同一個名稱的對象，在不一樣的BC中，是屬性徹底不同的不一樣的對象。
• 那爲什麼解決方案的邊界要叫作BC呢？對，咱們能夠不用叫作BC，好比你就叫作解決方案邊界，也沒問題。只是Eric在寫做DDD這本書時，把他叫作BC，因此咱們沿用了他的概念。咱們主要的目的是爲了用BC來表達解決方案空間的邊界。
• BC和子域的關係？沒有關係。由於它們是不一樣的東西被劃分後的產物，對解決方案空間進行劃分產生了BC，對領域劃分後產生了子域。並且它們劃分的依據也不一樣，因此一定會出現BC與子域的關係是1對1，1對多，多對1的各類可能性。注意，我說的是被劃分後的產物，因此這個產物叫什麼其實不重要，咱們真正要學會的是劃分的原則、依據、經驗，有了這些，咱們才能合理地劃分BC和子域。

領域模型

• 什麼是領域模型？這裏討論的領域模型是指DDD一書中提到的領域模型，領域模型是DDD軟件設計方法論中的核心概念，它是業務分析、軟件設計的綜合結果，是一個系統設計模型。領域模型存在於某個粒度解決方案空間裏。因此，任何一個領域模型，都是在特定的BC邊界內纔有意義；
• 領域模型和業務模型的區別：我以爲領域模型有一個引發人們誤會的地方，就是它的名稱。不少人容易把領域模型理解爲上面提到的業務模型，由於領域容易聯繫到業務，因此領域模型就是業務模型，好比很是著名的一本書《UML和模式應用》中，就認爲領域模型是需求分析階段的業務模型，是一種業務概念實體的模型。實際上二者是不一樣的，由於業務模型是對業務概念及其關係的表達，而領域模型在業務模型的基礎上，用OOA/D的思想進行進一步精煉和抽象的對象關係模型，並且領域模型中有聚合、實體、值對象的區分。舉亮個栗子：1）業務模型中，咱們可能會有買家、賣家、讀者、教師的業務概念，可是在領域模型中，咱們已經把這些概念抽象爲了帳號這個模型。2）再好比一個讀者持借書卡去圖書館借書這個場景，在業務模型中會存在一個借書卡的業務概念，而在領域模型中，咱們極可能會去掉借書卡，由於它只是一個借書的工具，是借書系統用來識別讀者的一個工具，系統真的的目的是爲了知道哪一個帳號在借書，而不關心如何識別出這個帳號。若是咱們有一個網上借書系統，那就不須要借書卡了，而是要提供帳號登陸功能。在DDD一書中，做者一步到位直接根據需求設計出領域模型，在提煉需求分析需求的過程當中直接應用軟件設計思想和抽象思惟一步到位產出領域模型，我我的以爲是有點快的，更好的作法應該是先分析出業務模型，再對業務模型進行精煉，獲得領域模型；
• 既然領域模型存在於某個粒度的解決方案空間中，而這個粒度的解決方案空間可能會對應多個子域。因此，這個領域模型則基於多個子域的業務模型結合起來推導出來的一個系統模型。同理，同一個子域內也可能有多個解決方案空間，既有多個BC，每一個BC內有一個領域模型；
• 那如何進行領域建模獲得領域模型呢？這個就比較複雜了，不過通過前面的討論，大體分爲兩個大的階段：1）先獲得業務模型；2）再對業務模型進行模型精煉；如何精煉？運用軟件設計思想和原則，以及概括演繹的抽象思惟；因此，領域建模歸根結底也是要「看狀況，憑經驗」，是否是很沮喪:)

微服務

最近幾年，微服務開始流行起來，把DDD也帶火了一把。那爲什麼微服務的流行會讓DDD也火起來呢？是由於微服務須要劃分，而DDD中的BC的概念，你們發現正好能夠和微服務的邊界徹底契合。好比都是對解決方案空間進行劃分，都按照各類軟件設計思想和原則進行劃分，都提倡零共享。不過，DDD中實際上對BC的描述沒有太多，尤爲是如何獲得BC這塊沒有展開。可能這塊對大師來講是天然而然的事情，不須要過多介紹吧。

概念總結

• 領域=問題域=問題空間=業務邊界
• 每一個粒度的問題域都會推導出一個業務模型
• 領域拆分、業務建模，是需求分析階段該作的事情
• 解決方案的邊界即BC，解決方案可拆分
• 每一個粒度的解決方案都會推導出一個領域模型
• 解決方案拆分、領域建模，是軟件設計階段該作的事情
• BC邊界即微服務邊界，不一樣BC內的解決方案的架構能夠是不一樣的，也即每一個微服務的架構能夠不一樣

原文出處：https://www.cnblogs.com/netfocus/p/DDD.html