實現領域驅動設計（簡體書）

Vaughn Vernon是一個經驗豐富的軟件工匠，在軟件設計、開發和架構方面擁有超過25年的從業經驗。他提倡通過創新來簡化軟件的設計和實現。從20世紀80年代開始，他便開始使用面向對象語言進行編程；在90年代早期，他便在領域建模中應用了領域驅動設計，那時他使用的是Smalltalk語言。他在全球範圍之內提供軟件諮詢和演講，此外，他還在許多國家教授《實現領域驅動設計》的課程。
滕雲，ThoughtWorks軟件工程師。當初抱著“非飛行器設計專業不讀”的理想加幻想考入西北工業大學，卻不料學起了汽車專業。在嘗盡了“從天上掉到地下”的滋味之後，又轉行躬耕於軟件開發。目前主要從事銀行、保險等領域的企業級軟件開發，感興趣的技術領域包括Java EE、Linux、領域驅動設計和構建自動化等。

所有的計算都表明它不工作，唯一的做法是：使其工作。--Pierre-Georges Latécoère早期法國航空企業家
是的，我們將使其工作。然而，在軟件開發過程中採用領域驅動設計卻是困難的。即便是有能力的開發者，也很難找到實現領域驅動設計的正確方法。
起飛，著陸
在我小的時候，我的父親學習過駕駛小型飛機。我們經常會全家出去飛行，有時會飛到另一個機場，在那裡吃過午飯後再返回。當父親時間有限而他依然想飛時，父親便帶上我一起在機場上空盤旋，起飛，著陸，再起飛，再著陸。
也會有些長途飛行，這時我們會帶上一張由父親先前繪製好的路線圖。我們幾個小孩便當起了領航員：將圖上的標誌對應著陸地上的地標，以確保我們沒有跑偏航線。這是一件很有趣的事情，因為要識別遠在地面上的物體是很有挑戰性的。事實上，我敢肯定父親根本不用我們領航便知道我們處於什麼方位--他能看到儀錶盤上的所有信息，並且他擁有儀表飛行執照。
空中的景觀的確改變了我的視野。不時地，父親和我會飛過我們鄉下的房子。在幾百英尺的高空中，我體會到了另一種“家”的概念，而這在之前是沒有過的。當我們飛過自家的房子時，母親和我的姐妹們便會跑到院子裡向我們揮手。我知道那是她們，即便我看不清楚她們是誰。談話肯定是不行的，連大聲喊都不行，她們是聽不見的。我還可以看到將我家和外面公路分開的護欄，平時我們會像走平衡木一樣在護欄上面走來走去。從空中看，它們就像被細心編排過的小樹枝一樣。我們
家的院子很大，每每到了夏天，我都會開著割草機一排一排地修理院子裡的草坪。而在空中時，我只能看到一片綠色，小草的葉子肯定是看不清楚的。
我喜歡在空中的時刻，直到現在我還不時回想起這些時刻，好像那個降落飛
機的黃昏就發生在不久以前一樣。雖然如此，在地面上的感覺依然是無法取代的，
因為它給我一種腳踏實地的感覺。
著陸於領域驅動設計
一開始接觸領域驅動設計（ DDD）就像一個小孩之於飛行一樣。天空中的景色是令人驚嘆的，但有時我們卻因為過於陌生而搞不明白它們到底是什麼。要從甲地到乙地顯得如此的遙遠。然而， DDD的“成年人“們卻總知道他們所處的方位，因為他們在很早之前便繪製好了路線圖，並且能夠完全按照儀表進行相應的操作。而還有很多人找不到”在地面上“的感覺，此時我們需要的是”穩定著陸“的能力，然後找到一張地圖給我們指引方向。
Eric Evans的《領域驅動設計：軟件核心複雜性應對之道》是一本經得住時間考驗的經典之作。我堅定地相信，在接下來的幾十年裡，本書依然會是開發者的實用指導。和其他模式一樣，該書為我們建立起了一種高屋建瓴式的寬闊視野。然而，對於如何實現DDD，我們可能將面對更多的挑戰。通常來說，我們更渴望看到一些具體的例子。
我的目標之一便是幫助你來一個”軟著陸“，保全飛機，然後沿著一條周知的線路帶你回家。這將幫助你如何更好地去實現DDD，並且通過你所熟悉的工具和技術給出示例演示。當然，任何一個人都不可能一直呆在家裡，所以我還會帶領你到新的地帶去冒險，這些地帶你可能從來沒有去過。冒險之路是險峻的，但是在正確的戰術應對下，征服這些困難是可能的。在這條冒險之路上，你將學到另外的架構和模式來集成多個領域模型。你將接觸到先前沒有被研究過的集成方法，並且學到如何開發自治性服務。
我將向你提供一張對短途旅行和長途旅行均適用的地圖，它可以幫助你更好地享受沿途風景，同時又不至於迷失途中。
對照地形，繪製飛行圖
在軟件開發的過程中，我們經常做的一件事便是將一種東西映射到另一種東西。我們將對象映射到數據庫，映射到用戶界面，或者映射到不同的應用層展現（包括作為消費方的其他系統或應用程序）。在所有這些映射中，我們很自然地希望在Evans提出的高層模式和具體實現之間存在一種映射。
即便你已經接觸過DDD，你依然有很多可以獲益的地方。有時， DDD首先被看作是一套技術工具集，有人將此稱為DDD-Lite。我們可能已經對實體、服務等DDD概念非常熟悉了，並且大膽地嘗試著設計聚合，還通過資源庫來管理持久化。這些模式是大家相對熟知的，使用起來很容易，我們甚至還使用了值對象。以上這些都屬於戰術設計模式範疇，也即更加偏向技術層面。這些模式可以很好地幫我們解決軟件問題。而同時，對於戰術性模式，我們依然有許多需要學習的。我將戰術模式映射到實現層面。
你曾了解過戰術建模之外的東西嗎？你曾了解過被稱為DDD”另一半“的戰略設計模式嗎？如果你還沒有使用過限界上下文和上下文映射圖，那麼你很有可能也沒有使用過通用語言。
如果說Evans在軟件開發社區有一項發明，那便是通用語言。通用語言是一種團隊協作模式，用於捕捉特定業務領域中的概念和術語。一個特定領域的軟件模型通過不同的名詞、形容詞和動詞來表達，這些詞彙是開發團隊正式使用的，而團隊中應該包含一個或多個領域專家。然而，將通用語言僅限定於一些詞彙則是錯誤的。就像自然語言反映人們的思想一樣， DDD的通用語言反映了領域專家對於軟件系統的思維模型。通用語言和那些戰略和戰術性的建模模式同等重要，在有些情況下甚至更具有持久性。
簡單地講， DDD-Lite將導致劣質的領域對象，因為通用語言、限界上下文和上下文映射圖的作用太大了，你從其中獲得的並不只是一套團隊共用的語言。在限界上下文中用通用語言來表述一個領域模型可以增加業務價值，並且使我們確信所開發軟件的正確性。即使從技術的角度，它也可以幫助我們創建更好的領域模型，這樣的模型行為豐滿，業務純淨，並且可以減少犯錯誤的可能性。因此，我將戰略設計模式映射到了可理解的實際例子中。
本書對於DDD的映射可以幫助你同時體會到戰略設計和戰術設計的好處。通過一些具體的例子，你將感受到這些DDD映射的業務價值和技術展現力。
如果我們對於DDD的所有實踐都只是停留在”地面上“，那將是令人失望的。過度地拘泥於細節將使我們喪失在空中俯瞰的機會。所以，不要將自己局限在地面的細節上，要勇敢地飛翔在空中，居高臨下。搭上戰略設計的航班，去了解限界上下文和上下文映射圖，你將獲得更廣闊的視野。當你從DDD的航班中獲益時，我的目的也就達到了。
各章概要
以下是各章的主要內容以及你將如何從中獲益。
第1章：DDD入門
本章向你介紹DDD的好處，並且教你如何盡可能多地去實現DDD。你將學到當你在應對複雜的軟件系統時， DDD可以為你的項目和團隊帶來什麼。同時，你將了解到通常的DDD替代方案以及這些方案為什麼會導致問題。作為對DDD的基礎講解，本章將教你如何在項目中開始採用DDD，還有如何向你的領域專家和技術團隊推銷DDD。在DDD的武裝下，你將學會如何迎接挑戰，勇往直前。
本章將介紹關於一個公司及其團隊的案例研究，雖然該公司是虛構的，但是他們所面臨的DDD挑戰卻是真實存在的。該公司旨在開發一個新的多租戶SaaS（Software as a Service，軟件即服務）軟件產品。不出所料，在使用DDD時，他們犯了一些常見的錯誤。不過還好，他們發現了這些錯誤，並解決了一些問題，因此項目還算沒有偏離正軌。該團隊需要開發一套基於Scrum的項目管理軟件。該案例還會在本書的後續章節中連續講到。每一種戰略和戰術模式都將教給這個團隊。在這個過程中，團隊有誤入歧途的時候，但最終他們將向著成功的DDD實踐昂首闊步。
第2章：領域、子域和限界上下文
領域、子域和核心域分別是什麼？限界上下文是什麼，我們為什麼要使用它，並且如何使用？這些問題將在這個SaaS項目團隊犯錯誤的時候給予解答。在他們的第一個DDD項目中，他們並不了解子域、限界上下文和通用語言這些概念。事實上，他們根本不知道什麼是戰略設計，只是採用了戰術設計來解決一些技術問題。這樣他們在開始設計領域模型的時候便遇到了不少問題。幸運的是，他們及時地意識到了這些問題，項目還有挽回的餘地。
本章還講到瞭如何使用限界上下文對模型進行分離，這是非常重要的；同時還講到了一些模型分離不當的反例，並且給出了有效的實現建議。在採用了這些建議之後，該團隊的成員們重新創建了兩個不同的限界上下文。這種合理的模型分離帶來的好處是引出了第三個限界上下文--核心域，這將是本書使用的主要例子。
對於那些苦於單單從技術層面應用DDD的人來說，本章應該能引起你的共鳴。如果你還是DDD戰略設計的外行，那麼本章將為你指明方向。
第3章：上下文映射圖
上下文映射圖幫助我們理解業務領域、模型間的邊界，以及這些模型之間的集成方式。
上下文映射圖絕對不只是繪製系統架構圖這麼簡單，它處理的是不同限界上下文之間的關係，以及如何在不同的模型之間映射對象。對於在復雜的業務系統中使用好限界上下文，這是至關重要的。在第2章中，團隊成員們在首次嘗試限界上下文時碰到了問題。本章中，他們將學著如何利用上下文映射圖來解決這些問題。這樣的結果是產生了兩個體面的限界上下文，這兩個上下文將被另外一個負責核心域的團隊所使用。
第4章：架構
我們都知道分層架構，但它是開發DDD軟件的唯一方式嗎，也或許還存在另外的方式？在本章中，我們將講到：六邊形架構（端口和適配器）、面向服務架構、REST、CQRS、事件驅動（管道和過濾器，長時處理過程，事件源）和數據網格，其中好幾種架構都將被該團隊成員所採用。
第5章：實體
在DDD的戰術模式中，我們將首先講到實體。團隊成員們一開始過於強調實體的作用而忽視了值對象。受到數據庫和持久化框架的影響，實體被該團隊濫用了，此時他們開始討論如何避免大範圍地使用實體。
在本章中，你將看到很多優秀的實體設計例子。同時，本章還將講到如何使用實體來表達通用語言，以及如何對實體進行測試、實現和持久化。
第6章：值對象
早些時候，團隊成員們錯過了採用值對象的好機會。他們過於注重為實體創建一些單一的屬性，這種方式是欠妥的，更好的方式是將這些單一的屬性聚合成一個不變的整體。本章將從不同的角度講解如何設計值對象，以及在什麼時候採用值對象會優於實體。同時，本章還包含了一些其他話題，比如值對像在集成中的角色和對標準類型的建模等。然後，本章講到瞭如何設計以領域為中心的測試，如何實現值對象。此外，本章還講到了在聚合中存儲值對象時，如何避免持久化機制所帶來的不利影響。
第7章：領域服務
本章將講到，在領域模型中，什麼時候應該將一個概念建模成粒度適中，並且無狀態的領域服務。你將學到何時應該使用領域服務而不是實體或值對象，以及如何使用領域服務來處理業務邏輯和技術上的集成。團隊成員們向我們展示了何時應該使用領域服務，以及如何設計領域服務。
第8章：領域事件
Eric Evans並沒有在他的書中正式介紹領域事件，領域事件是在他那本書出版之後才進入人們視野的。在本章中，你將學到為什麼領域事件如此有用，以及使用領域事件的不同方法。領域事件甚至被用來輔助集成和自治性服務。在軟件系統中，我們經常使用一些技術層面的事件機制，但本章將著重講解領域事件與這些事件機制的區別。本章還將指導你如何設計並實現領域事件，包括一些可行的方案和對這些方案的權衡選擇。然後，本章將講到如何創建一個發布-訂閱機制；如何利用事件來集成整個企業軟件中的各個訂閱方；如何創建和管理事件存儲；如何處理消息機制所面臨的常見挑戰等。
第9章：模塊
對於模型中的對象，我們應該如何將他們組織在大小適中的容器中呢？我們又如何保證不同容器中的對象之間只存在有限的耦合？另外，我們如何對這些容器進行命名以體現通用語言？除了包和命名空間之外，我們如何使用由語言和框架提供的現代模塊化機制，比如OSGi和Jigsaw？在本章中，你將看到SaaS團隊成員是如何在不同的項目中使用模塊的。
第10章：聚合
在DDD的戰術模式中，聚合可能是最不容易理解的了。然而，在遵循一定的經驗法則的情況下，我們是能夠更簡單、更快地實現聚合的。在本章中你將學到：如何利用聚合在不同的小規模對象集群間創建一致性邊界，從而降低模型的複雜性。由於在細枝末節上花了太多精力， SaaS團隊成員們在設計聚合時總是磕磕絆絆。我們將仔細研究該團隊所面臨的挑戰，並且分析錯誤的原因以及他們的應對策略。結果，團隊成員們對他們的核心域有了更深層次的理解。我們將看到，在合理的事務處理和保證最終一致性（Eventual Consistency）的前提下，該團隊更正了他們所犯的錯誤，並且在一個分佈式環境中設計出了更具有伸縮性和更高效的模型。
第11章：工廠
工廠已經在[Gamma et al.]中被大量地談及了，為什麼還要講呢？本章並不打算重蹈覆轍，而是將重點放在”工廠應該存在於何處“這個問題上。在本章中，我們將講到在DDD中實現工廠的技巧。團隊成員在他們的核心域中創建的工廠可以簡化客戶端接口，並且對模型的消費方起到保護作用，從而避免了在多租戶環境中引入災難性的bug。
第12章：資源庫
資源庫只是一個數據訪問對象（ Data Access Object， DAO）嗎？如果不是，它們之間有什麼區別呢？我們為什麼應該將資源庫看成是對集合的模擬而非數據庫呢？在本章中，我們將講到如何利用ORM來實現資源庫，其中有兩種ORM方案，一種採用基於網格的分佈式緩存，另一種則採用NoSQL的鍵值對存儲。團隊成員們可以採用任何一種作為他們的持久化機制。
第13章：集成限界上下文
到現在為止，你已經了解了戰略層次的上下文映射圖和多種戰術層次的模式。本章將講到，在DDD中，我們如何通過上下文映射圖來集成不同的模型。在團隊對核心域和其他輔助性的限界上下文進行集成時，我們將給出相應的建議和指導。
第14章：應用程序
對於每一個核心域的通用語言，我們都設計了相應的模型，並且進行了足夠的測試，模型工作正常。然而，客戶應該如何使用我們的模型呢？他們應該使用DTO將數據在模型和用戶界面之間傳輸嗎？或者存在其他方案可以實現模型和展現組件間的數據傳遞？DDD中的應用服務和基礎設施是如何工作的？對於這些問題，本章都將做出解答。
附錄A：聚合與事件源： A+ES
事件源是一種持久化聚合的重要技術，同時也是事件驅動架構的基礎。事件源通過一系列的事件來表示聚合的所有狀態。通過有序的事件重放，我們可以重新構建聚合的狀態。當然，使用事件源的前提是：它能夠簡化對數據的持久化，並且能夠捕捉到那些具有復雜行為屬性的概念。
Java和開發工具
本書中的絕大多數例子都是使用Java語言編寫的。我本來可以用C#的，但是我有意識地使用了Java。
首先，我認為Java社區正在拋棄好的軟件設計和開發實踐。現在，對於多數Java項目而言，要在其中找到一個好的領域對象恐怕是困難的。在我看來， Scrum和敏捷被人們看成了優良設計的替代品，而其中的產品待定項（Product Backlog）被看成了設計本身。多數敏捷人士並不會過多地去思考這些待定項是否會影響到業務模型。我得說明， Scrum的本意絕對不是要取代設計。不管有多少項目經理想將你捆綁在持續交付這條路上，我得說Scrum並不僅僅是要取悅於那些甘特圖（ Gantt chart）的追隨者們。然而，太多的時候，情況的確是這樣的。
我認為這是個很大的問題，所以我想鼓勵Java社區重新回到領域建模中來，同時我會通過本書向大家說明，設計是可以使我們獲益的。
此外，在.NET社區中已經有很好的DDD資源了，比如Jimmy Nilsson的《領域驅動設計與模式實戰》[Nilsson]。由於Jimmy的出色工作和其他人對Alt.NET的倡導，.NET社區中正掀起一陣優秀設計的開發浪潮，這是Java社區需要注意的。
其次，我意識到C#.NET人員在理解Java代碼上並不存在什麼困難。由於很多DDD社區的人都在使用C#.NET，而本書的早期校對人員也都是C#程序員，但是我從來就沒有收到他們的抱怨。因此，我便不用顧慮這些了。
在我寫這本書時，業內正將目光從關係型數據庫轉向基於文檔和鍵值對的存儲方案。這是有原因的， Martin Fowler將這些存儲方案稱為”面向聚合存儲“。這種命名是恰當的，它很好地描述了在DDD中使用NoSQL的好處。
但是，就我從事諮詢的經驗來看，很多開發者還是認定了關係型數據庫和對象-關係映射。因此我想， NoSQL追隨者們應該能夠理解我在書中包含對象-關係映射的章節。然而，我的確得承認，這可能會招致那些認為存在對象-關係阻抗失配（Object-Relational Impedance）的人的鄙視。這無所謂，對此我表示接受，因為絕大多數人在他們的日常工作中都還得面對這種對象-關係阻抗失配。
當然，在第12章”資源庫“中，我同樣提供了基於文檔的、鍵值對的和數據網格的存儲方案。在多處地方，我都討論到了NoSQL對聚合設計的影響。NoSQL趨勢很有可能持續下去，那些對象-關係型的開發者們應該注意了。在本書中你將看到，我能夠同時理解兩個陣營的觀點，並且對於雙方的觀點我都同意。這些都是技術趨勢所導致的摩擦，而這對於積極的變革是有必要的。

目錄
序xix
前言xxi
致謝xxxi
關於作者xxxv
如何使用本書xxxvii
第1章DDD入門1
我能DDD嗎？2
為什麼我們需要DDD 5
如何DDD 17
使用DDD的業務價值22
1你獲得了一個非常有用的領域模型22
2你的業務得到了更準確的定義和理解23
3領域專家可以為軟件設計做出貢獻23
4更好的用戶體驗23
5清晰的模型邊界24
6更好的企業架構24
7敏捷、迭代式和持續建模24
8使用戰略和戰術新工具24
實施DDD所面臨的挑戰25
虛構的案例，真實的實踐33
本章小結36
第2章領域、子域和限界上下文37
總覽37
工作中的子域和限界上下文38
將關注點放在核心域上42
戰略設計為什麼重要45
現實世界中領域和子域48
x目錄
理解限界上下文53
限界上下文不僅僅只包含模型57
限界上下文的大小59
與技術組件保持一致61
示例上下文62
協作上下文63
身份與訪問上下文69
敏捷項目管理上下文71
本章小結73
第3章上下文映射圖75
上下文映射圖為什麼重要75
繪製上下文映射圖77
產品和組織關係79
映射3個示例限界上下文82
本章小結97
第4章架構99
採訪一個成功的CIO100
分層104
依賴倒置原則107
六邊形架構（端口與適配器） 110
面向服務架構114
REST 117
REST作為一種架構風格117
RESTful HTTP服務器的關鍵方面118
RESTful HTTP客戶端的關鍵方面119
REST和DDD 120
為什麼是REST？121
命令和查詢職責分離――CQRS121
CQRS的各個方面123
處理具有最終一致性的查詢模型128
事件驅動架構129
目錄xi
管道和過濾器131
長時處理過程（也叫Saga） 134
事件源140
數據網織和基於網格的分佈式計算143
數據複製144
事件驅動網織和領域事件145
持續查詢145
分佈式處理146
本章小結148
第5章實體149
為什麼使用實體149
唯一標識151
用戶提供唯一標識152
應用程序生成唯一標識153
持久化機制生成唯一標識156
另一個限界上下文提供唯一標識160
標識生成時間161
委派標識163
標識穩定性165
發現實體及其本質特徵167
揭開實體及其本質特徵的神秘面紗168
挖掘實體的關鍵行為172
角色和職責176
創建實體181
驗證183
跟踪變化192
本章小結192
第6章值對象193
值對象的特徵194
度量或描述195
不變性195
xii目錄
概念整體196
可替換性199
值對象相等性200
無副作用行為201
最小化集成204
用值對象表示標準類型206
測試值對象210
實現214
持久化值對象219
拒絕由數據建模洩漏帶來的不利影響220
ORM與單個值對象221
多個值對象序列化到單個列中224
使用數據庫實體保存多個值對象225
使用聯合表保存多個值對象229
ORM與枚舉狀態對象230
本章小結233
第7章領域服務235
什麼是領域服務（首先，什麼不是領域服務） 237
請確定你是否需要一個領域服務238
建模領域服務241
獨立接口有必要嗎244
一個計算過程246
轉換服務249
為領域服務創建一個迷你層250
測試領域服務250
本章小結253
第8章領域事件255
何時/為什麼使用領域事件255
建模領域事件258
創建具有聚合特徵的領域事件263
身份標識264
目錄xiii
從領域模型中發布領域事件265
發送方265
訂閱方269
向遠程限界上下文發布領域事件271
消息設施的一致性271
自治服務和系統272
容許時延273
事件存儲274
轉發存儲事件的架構風格279
以REST資源的方式發布事件通知279
通過消息中間件發布事件通知283
實現284
發布NotificationLog 285
發布基於消息的事件通知290
本章小結297
第9章模塊299
通過模塊完成設計299
模塊的基本命名規範302
領域模型的命名規範302
敏捷項目管理上下文中的模塊305
其他層中的模塊308
先考慮模塊，再是限界上下文309
本章小結310
第10章聚合311
在Scrum核心領域中使用聚合312
第一次嘗試：臃腫的聚合313
第二次嘗試：多個聚合314
原則：在一致性邊界之內建模真正的不變條件317
原則：設計小聚合319
不要相信每一個用例321
原則：通過唯一標識引用其他聚合322
xiv目錄
通過標識引用使多個聚合協同工作324
建模對象導航性325
可伸縮性和分佈式326
原則：在邊界之外使用最終一致性327
誰的任務？328
打破原則的理由329
理由之一：方便用戶界面329
理由之二：缺乏技術機制330
理由之三：全局事務331
理由之四：查詢性能331
遵循原則332
通過發現，深入理解332
重新思考設計332
估算聚合成本334
常見用例場景335
內存消耗336
探索另外的設計337
實現最終一致性338
這是Scrum團隊成員的任務嗎？339
決定的時候到了341
實現341
創建具有唯一標識的根實體342
優先使用值對象343
使用迪米特法則和“告訴而非詢問”原則344
樂觀並發346
避免依賴注入348
本章小結349
第11章工廠351
領域模型中的工廠351
聚合根中的工廠方法352
創建CalendarEntry實例353
創建Discussion實例357
目錄xv
領域服務中的工廠358
本章小結361
第12章資源庫363
面向集合資源庫364
Hibernate實現369
TopLink實現377
面向持久化資源庫379
Coherence實現381
MongoDB實現386
額外的行為391
管理事務393
警告397
類型層級397
資源庫vs數據訪問對象（DAO） 400
測試資源庫401
以內存實現進行測試404
本章小結407
第13章集成限界上下文409
集成基礎知識409
分佈式系統之間存在根本性區別411
跨系統邊界交換信息411
通過REST資源集成限界上下文417
實現REST資源418
使用防腐層實現REST客戶端421
通過消息集成限界上下文428
從Scrum的產品負責人和團隊成員處得到持續通知428
你能處理這樣的職責嗎？434
長時處理過程，以及避免職責439
長時處理過程的狀態機和超時跟踪器450
設計一個更複雜的長時處理過程460
xvi目錄
當消息機製或你的系統不可用時464
本章小結465
第14章應用程序467
用戶界面469
渲染領域對象470
渲染數據傳輸對象471
使用調停者發布聚合的內部狀態471
通過領域負載對象渲染聚合實例472
聚合實例的狀態展現473
用例優化資源庫查詢474
處理不同類型的客戶端474
渲染適配器以及處理用戶編輯475
應用服務478
示例應用服務478
解耦服務輸出485
組合多個限界上下文487
基礎設施489
企業組件容器490
本章小結494
附錄A聚合與事件源：A+ES 495
應用服務內部496
命令處理器505
Lambda語法508
並發控制510
A+ES所帶來的結構自由性513
性能513
實現事件存儲516
關係型持久化520
BLOB持久化522
專注的聚合523
讀模型投射524
目錄xvii
與聚合設計一道使用527
增強事件527
工具和模式529
事件序列器530
事件不變性531
值對象531
協議生成534
單元測試和需求規範535
事件源和函數式語言536
參考文獻539

當然，對於“當……的時候，請通知我”，這裡的通知本身並不能構成一個事件，而只是表明我們需要向外界發出通知。另外，領域專家可能還會說“如果發生這樣的事情，它並不重要；如果發生那樣的事情，它就很重要了（將“這樣”和“那樣”用你自己領域中的事件予以替換） 。”根據你的組織文化，可能還有更多的事件用語。
牛仔的邏輯
有時，從領域專家的話中，我們看不出領域事件的跡象，但是業務需求依然有可能需要領域事件。領域專家有可能意識不到這些需求，只有在跨團隊討論之後他們才能意識到這些。發生這樣的事情往往是由於領域事件需要發佈到外部系統中，比如發佈到另一個限界上下文中（2）。由於這樣的事件由訂閱方處理，它將對本地和遠程上下文產生深遠的影響。
領域專家和領域事件
雖然領域專家在起初可能意識不到所有類型的領域事件，但是通過討論之後，他們是應該能夠了解到其中的原因的。當團隊成員對領域事件達成一致之後，領域事件便是通用語言的正式組成部分了。
當領域事件到達目的地之後一一無論是本地系統還是外部系統一一我們通常都將領域事件用於維護事件的一致性。這是有意而為之的，並且是根據設計而來的。這樣可以消除兩階段提交（全局事務），還可以支持聚合（10）原則。聚合的其中一個原則是，在單個事務中，只允許對一個聚合實例進行修改，由此產生的其他改蠻必須存單獨的事務中完成。

……