出處:

領域驅動設計中定義了超多的概念，如果不多找幾篇資料綜合的去看，什么叫做領域，正確的理解比較困難，下面搜集整理了大部分的領域驅動中的概念，并加以理解描述。

戰略設計與戰術設計

戰術設計則從技術視角出發，側重于領域模型的技術實現，完成軟件開發和落地，包括：聚合根、實體、值對象、領域服務、應用服務和資源庫等代碼邏輯的設計和實現。它主要關注的是技術層面的實施，也是對我們程序員最實在的地方。戰術設計的具體落地案例在后面的內容中會講解。

領域 & 子領域

DDD 的領域就是這個邊界內要解決的業務問題域。既然領域是用來限定業務邊界和范圍的，那么就會有大小之分，領域越大，業務范圍就越大，反之則相反。領域可以進一步劃分為子領域。我們把劃分出來的多個子領域稱為子域，每個子域對應一個更小的問題域或更小的業務范圍。

核心域 & 通用域 & 支撐域

在領域不斷劃分的過程中，領域會細分為不同的子域，子域可以根據自身重要性和功能屬性劃分為三類子域，它們分別是：核心域、通用域和支撐域。決定產品和公司核心競爭力的子域是核心域，它是業務成功的主要因素和公司的核心競爭力。沒有太多個性化的訴求，同時被多個子域使用的通用功能子域是通用域。還有一種功能子域是必需的，但既不包含決定產品和公司核心競爭力的功能，也不包含通用功能的子域，它就是支撐域。

事件風暴

事件風暴是一項團隊活動，領域專家與項目團隊通過頭腦風暴的形式，羅列出領域中所有的領域事件，整合之后形成最終的領域事件集合，然后對每一個事件，標注出導致該事件的命令，再為每一個事件標注出命令發起方的角色。命令可以是用戶發起，也可以是第三方系統調用或者定時器觸發等，最后對事件進行分類，整理出實體、聚合、聚合根以及限界上下文。而事件風暴正是 DDD 戰略設計中經常使用的一種方法，它可以快速分析和分解復雜的業務領域，完成領域建模。

通用語言 & 界限上下文

在 DDD 領域建模和系統建設過程中，有很多的參與者，包括領域專家、產品經理、項目經理、架構師、開發經理和測試經理等。對同樣的領域知識，不同的參與角色可能會有不同的理解，那大家交流起來就會有障礙，怎么辦呢？因此，在 DDD 中就出現了“通用語言”和“限界上下文”這兩個重要的概念。這兩者相輔相成，通用語言定義上下文含義，限界上下文則定義領域邊界，以確保每個上下文含義在它特定的邊界內都具有唯一的含義，領域模型則存在于這個邊界之內。

通用語言

界限上下文

領域的意思是：具體指一種特定的范圍或區域。1、拼音：lǐnɡ yù 2、近義詞：界線、范疇、范圍、界限、畛域 3、引證解釋：（1）現代·徐遲《牡丹》：這些演出和演奏，又把魏紫帶進了藝術的領域之中。（2）現代·袁鷹 。

用來封裝通用語言和領域對象，提供上下文環境，保證在領域之內的一些術語、業務相關對象等（通用語言）有一個確切的含義，沒有二義性。這個邊界定義了模型的適用范圍，使團隊所有成員能夠明確地知道什么應該在模型中實現，什么不應該在模型中實現。

1、首先，領域是集合的一種概念，也就是說，領域是無限數值的一個集合，集合的性質領域都是滿足的，例如：x0∈(x0-δ,x0+δ)；2、其次，領域必定是確定以某個變量為中心的集合，因為領域是從微積分中發展過來的，因。

栗子說明

在商品域，商品實體則對應著一個具體的 SKU 商品，包含著標題和金額，如現在的課程、會員服務。在訂單域中的商品實體并不等同域商品域中的實體，比如可以將優惠券做成可以被售賣的商品，coupon_no 就是 product_key，具有 non-consumable 屬性；或者將付費咨詢的用戶服務打包成商品售賣，那么 member_id 就能映射成 producer_key，并且覺有 consumable 屬性。界限上下文就是區分不同領域下的領域對象，劃定了領域對象含義的邊界。在訂單域中，商品實體默認可以是商品系統 SKU，也可以是優惠券和用戶服務等。

上下文映射圖

上下文映射圖就通過畫圖的方式展示N（N>=2）個上下文之間的映射關系。

ACL表示防腐層，OHS表示開放主機服務，PL表示發布語言，U代表上游，D代表下游。

領域服務

你是否遇到過這樣的問題：想建模一個領域概念，把它放在實體上不合適，把它放在值對象上也不合適，然后你冥思苦想著自己的建模方式是不是出了問題。恭喜你，祝賀你，你的建模手法完全沒有問題，只是你還沒有接觸到領域服務（Domain Service）這個概念，因為領域服務本來就是來處理這種場景的。比如，要對客戶端類型和版本進行判斷是否支持某一項功能，我們可以創建一個 ClientVersionService 來負責。值得一提的是，領域服務和上文中提到的應用服務是不同的，領域服務是領域模型的一部分，而應用服務不是。應用服務是領域服務的客戶，它將領域模型變成對外界可用的軟件系統。

領域事件

在DDD中，領域事件便可以用于處理上述問題，此時最終一致性取代了事務一致性，通過領域事件的方式達到各個組件之間的數據一致性。領域事件的命名遵循英語中的“名詞+動詞過去分詞”格式，即表示的是先前發生過的一件事情。比如，購買者提交商品訂單之后發布 OrderCreated 事件，用戶支付 TradePaid 事件。需要注意的是，既然是領域事件，他們便應該從領域模型中發布。領域事件的最終接收者可以是本限界上下文中的組件，也可以是另一個限界上下文。領域事件的額外好處在于它可以記錄發生在軟件系統中所有的重要修改，這樣可以很好地支持程序調試和商業智能化。另外，在CQRS架構的軟件系統中，領域事件還用于寫模型和讀模型之間的數據同步。再進一步發展，事件驅動架構可以演變成事件源（Event Sourcing），即對聚合的獲取并不是通過加載數據庫中的瞬時狀態，而是通過重放發生在聚合生命周期中的所有領域事件完成。

實體 & 值對象 & 聚合 & 聚合根

在玄幻小說中，“領域”還表示一種能力的體現，是高級本領中的一種，指完全受自己控制、人為產生的空間，它使制造者在戰斗中可獲得極大的優勢。字典中的意思 ①猶指領土。國家主權管轄下的區域：國家領域神圣不可侵犯。②。

實體 & 值對象

實體和值對象是組成領域模型的基礎單元。在 DDD 中有這樣一類對象，它們擁有唯一標識符，且標識符在歷經各種狀態變更后仍能保持一致。對這些對象而言，重要的不是其屬性，而是其延續性和標識，對象的延續性和標識會跨越甚至超出軟件的生命周期。我們把這樣的對象稱為實體。通過對象屬性值來識別的對象，它將多個相關屬性組合為一個概念整體。在 DDD 中用來描述領域的特定方面，并且是一個沒有標識符的對象，叫作值對象。值對象本質就是一個集合，可以保證屬性歸類的清晰和概念的完整性。

舉例說明

消費者實體原本包括：ID、昵稱、注冊手機號、姓名以及人員所在的省、市、縣和街道等屬性。這樣顯示地址相關的屬性就很零碎了對不對？現在，我們可以將“省、市、縣和街道等屬性”拿出來構成一個“地址屬性集合”，這個集合就是值對象了。

聚合 & 聚合根

聚合是業務和邏輯緊密關聯的實體和值對象組合而成，聚合是數據修改和持久化的基本單元，一個聚合對應一個數據的持久化。聚合在DDD分層架構中屬于領域層，領域層包含了多個聚合，共同實現核心業務邏輯，聚合內的實體以充血模型實現個體業務能力，以及業務邏輯的高內聚。跨多個實體的業務邏輯通過領域服務來實現，跨多個聚合的業務邏輯通過應用服務來實現。如果把聚合比作組織，聚合根則是組織的負責人，聚合根也叫做根實體，它不僅僅是實體，還是實體的管理者。聚合之間通過聚合根關聯引用，如果需要訪問其他聚合的實體，先訪問聚合根，再導航到聚合內部的實體。即外部對象不能直接訪問聚合內的實體。

舉例說明

上圖說明聚合與聚合根的關系，交易聚合有一個唯一的聚合根交易單，交易單組織了消費者實體、商品實體、商鋪實體、優惠券實體同時消費金額之對象。下面具體對比說明下：

聚合的特點：高內聚、低耦合，它是領域模型中最底層的邊界，可以作為拆分微服務的最小單位，但我不建議你對微服務過度拆分。但在對性能有極致要求的場景中，聚合可以獨立作為一個微服務，以滿足版本的高頻發布和極致的彈性伸縮能力。一個微服務可以包含多個聚合，聚合之間的邊界是微服務內天然的邏輯邊界。有了這個邏輯邊界，在微服務架構演進時就可以以聚合為單位進行拆分和組合了，微服務的架構演進也就不再是一件難事了。聚合根的特點：聚合根是實體，有實體的特點，具有全局唯一標識，有獨立的生命周期。一個聚合只有一個聚合根，聚合根在聚合內對實體和值對象采用直接對象引用的方式進行組織和協調，聚合根與聚合根之間通過 ID 關聯的方式實現聚合之間的協同。實體的特點：有 ID 標識，通過 ID 判斷相等性，ID 在聚合內唯一即可。狀態可變，它依附于聚合根，其生命周期由聚合根管理。實體一般會持久化，但與數據庫持久化對象不一定是一對一的關系。實體可以引用聚合內的聚合根、實體和值對象。值對象的特點：無 ID，不可變，無生命周期，用完即扔。值對象之間通過屬性值判斷相等性。它的核心本質是值，是一組概念完整的屬性組成的集合，用于描述實體的狀態和特征。值對象盡量只引用值對象。

防腐層

通過在遺留系統和現代系統之間使用防腐層來隔離它們。該層轉換兩個系統之間的通信，允許遺留系統保持不變，同時可以避免損害現代應用程序的設計和技術方法。

現代應用與防腐層之間的通信始終使用應用程序的數據模型和架構。從防腐層到遺留系統的調用都符合該系統的數據模型或方法。 防腐層包含兩個系統之間轉換所需的所有邏輯。該層可以作為應用程序中的組件或作為獨立服務來實現。

貧血模型

領域的意思是：一國主權所達之地。還有一種意思是：從事一種專門活動或事業的范圍、部類或部。網絡解釋：領域（漢語詞語）領域是一個漢語詞語，發音是lǐnɡyù，有生物學概念，數學概念等多重意義。出自（南朝宋）劉義慶《。

貧血模型就是模型對象之間存在完整的關聯(可能存在多余的關聯)，但是對象除了get和set方外外幾乎就沒有其它的方 法，整個對象充當的就是一個數據容器，用C語言的話來說就是一個結構體，所有的業務方法都在一個無狀態的Service類中實現，Service類僅僅包 含一些行為。貧血模型的優點是很明顯的：

被許多程序員所掌握，許多教材采用的是這種模型，對于初學者，這種模型很自然，甚至被很多人認為是java中最正統的模型。

它非常簡單，對于并不復雜的業務(轉帳業務)，它工作得很好，開發起來非常迅速。它似乎也不需要對領域的充分了解，只要給出要實現功能的每一個步驟，就能實現它。

事務邊界相當清楚，一般來說service的每個方法都可以看成一個事務，因為通常Service的每個方法對應著一個用例。（在這個例子中我使用了facade作為事務邊界，后面我要講這個是多余的)其缺點為也是很明顯的：

企業回咨詢一下北京海致星圖科技有限公司，北京海致星圖科技有限公司致力于利用知識圖譜幫助機構整合數據、分析關聯產生真正智能的結果，從而提供給社會更好的服務，讓技術更直接的提高生產力，有著豐富的經驗與廣泛的成功案例，是企業知識圖譜開創者。

將所有的業務放在無狀態的service中實際上是一個過程化的設計，它在組織復雜的業務存在天然的劣勢，隨著業務的復雜，業務會在service中多個方法間重復。

當添加一個新的UI時，很多業務邏輯得重新寫。例如，當要提供Web Service的接口時，原先為Web界面提供的service就很難重用，導致重復的業務邏輯（在貧血模型的分層圖中可以看得更清楚），如何保持業務邏輯一致是很大的挑戰。

領域模型

領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系。領域驅動模型，與貧血模型相反，領域模型要承擔關鍵業務邏輯，業務邏輯在多個領域對象之間分配，而Service只是完成一些不適合放在模型中的業務邏輯，它是非常薄的一層，它指揮多個模型對象來完成業務功能。其優點是：

領域模型采用OO設計，通過將職責分配到相應的模型對象或Service，可以很好的組織業務邏輯，當業務變得復雜時，領域模型顯出巨大的優勢。

當需要多個UI接口時，領域模型可以重用，并且業務邏輯只在領域層中出現，這使得很容易對多個UI接口保持業務邏輯的一致(從領域模型的分層圖可以看得更清楚)。其缺點是：

對程序員的要求較高，初學者對這種將職責分配到多個協作對象中的方式感到極不適應。

領域驅動建模要求對領域模型完整而透徹的了解，只給出一個用例的實現步驟是無法得到領域模型的，這需要和領域專家的充分討論。錯誤的領域模型對項目的危害非常之大，而實現一個好的領域模型非常困難。

對于簡單的軟件，使用領域模型，顯得有些殺雞用牛刀了。

開放主機服務

該模式可以通過REST實現。通常來講，我們可以將開放主機服務看作是遠程過程調用（RPC）的API。同時，也可以通過消息機制實現。

參考

出處: