如何使用本書

Eric Evans在他那本《領域驅動設計》中向我們展示了一整套模式語言。模式語言是相互關聯的眾多軟件模式的一個集合，任何一種模式都會引用并依賴于其他一種或多種模式。這意味著什么呢？

這意味著當你在閱讀本書時，某個章節中出現的有些DDD模式并不會在該章節中講到，甚至在該章節之前都沒有被談及到。不要擔心，繼續往下讀，被引用的模式將在本書的其他章節中做詳細講解。

在本書中，我將使用下表中的行文慣例：

在閱讀的過程中，如果遇到對某個模式的引用，比如限界上下文，此時你通常可以在另外某個章節找到對該模式的講解。

如果你已經讀過[Evans]，并且對其中的模式有一定的了解，那么本書可以幫助你進一步澄清DDD的概念，然后引導你對既有的模型進行改進。此時你可能并不需要一個總覽式的介紹。但是，如果你還是DDD的新手，那么下面的內容將為你講到不同的DDD模式是如何協同工作的，并且如何更好地使用本書，接著往下讀吧。

DDD總覽

早些時候，我講到了DDD的通用語言（Ubiquitous Language，1）。通用語言作用于某個限界上下文（Bounded Context，2），它對于領域建模是非常重要的，你應該好好地熟悉一下。請記住，不管你是在戰術上還是戰略上設計軟件模型，你都應該保證：在一個特定的限界上下文中只使用一套通用語言，并且保證它的清晰性和簡潔性。

戰略建模

限界上下文是一種概念上的邊界，領域模型便工作于其中。同時，限界上下文為通用語言提供了一套環境，項目成員便通過通用語言來表達軟件模型，如圖G.1所示。

在戰略設計的過程中，你將發現上下文映射圖（Context Map，3）是非常有用的，如圖G.2所示。你的團隊將使用上下文映射圖來理解項目的范圍。

以上我們簡要地了解了DDD的戰略設計，這是我們必須好好理解的概念。

架構

有時，一個新的限界上下文或上下文映射圖可能需要一種新的架構（Architecture，4）。你應該牢記：通過戰略和戰術設計而成的領域模型應該是架構中立的。當然，在模型周圍和模型之間則是存在架構的。一種能夠支撐限界上下文的架構是六邊形（Hexagonal）架構，它可以輔助其他架構風格，比如面向服務（Service-Oriented）架構、REST和事件驅動（Event-Driven）等。六邊形架構如圖G.3所示，從表面看，這種架構有點復雜，但是事實上卻恰恰相反。

有時我們過于強調架構而忽略了DDD建模的重要性。架構固然是好的，但是架構并非一成不變。此時我們須要正確地處理優先級，將重點放在領域模型上，因為領域模型將產生更多的業務價值，并且更具有持久性。

戰術建模

我們在限界上下文中進行DDD的戰術建模。戰術設計的一個重要模式是聚合（Aggregate，10），如圖G.4所示。

聚合可以由單個實體（Entity，5）組成，也可以由一組實體和值對象（Value Object，6）組成，此時我們必須在聚合的整個生命周期中保證事務上的一致性。有效地對聚合進行建模是重要的，同時聚合又是DDD中最不容易理解的概念之一。你可能會問，既然聚合如此重要，那為什么要將其放在本書的后面呢？首先，本書中戰術模式的出現順序和[Evans]一樣，此外，由于聚合以其他戰術模式為基礎，所以我們會先講到實體、值對象等基本模式，再講解聚合。

聚合實例通過資源庫（Repository，12）進行持久化，另外，對聚合的查找和獲取也通過資源庫完成，如圖G.4所示。

在領域模型中，有些業務操作并不能自然地放在實體或值對象上，此時我們可以使用無狀態的領域服務（Domain Service，7），如圖G.5所示。

領域事件（Domain Event，8）表示領域模型中發生的重要事件。有多種方式可以對領域事件進行建模。在對聚合進行命令操作時，聚合本身將發布領域事件，如圖G.6所示。

我們通常忽略了模塊（Module，9），但是正確地設計模塊同樣是重要的。簡單來講，我們可以將模塊看成是Java中的包或C#中的命名空間。請記住，如果只是機械式地設計模塊，而不是根據通用語言，那么我們將得不償失。模塊中包含的領域對象應該是內聚在一起的，如圖G.7所示。

好吧，現在來熟悉一下“牛仔的邏輯”幽默片段，以下便是一則：

牛仔的邏輯

AJ：“不要擔心你的嘴巴包不下這塊大肥肉，你的嘴巴可比你想象的大多了。”

LB：“你說的是‘頭腦’吧，J。你的頭腦比想象的大多了才對。”