實踐篇 | DDD概念複雜難懂，實際落地如何設計程式碼實現模型？

在分析DDD程式碼實現模型時，對於上一篇提到的四個組成部分，我們需要梳理它們的 程式碼結構和依賴關係 。針對程式碼結構，我們需要明確程式碼包的組成，以及內部所包含的技術元件。

在明確了包結構之後，依賴關係指的是我們需要進一步明確這些程式碼包和技術元件之間的互動關係。基於這兩點，讓我們先來討論領域物件 的程式碼實現模型。

▶︎   領域物件程式碼實現模型

針對領域物件，我們通常用“domain”這個單詞，對程式碼包結構的頂層包進行命名，在該包結構下的所有技術元件，都屬於領域物件的範疇。

具體而言，在DDD中，領域物件包括領域模型物件、領域事件、資源庫以及應用服務所涉及到的命令和查詢物件，其中領域模型物件可以分為聚合、實體和值物件這三大類。

因此，在DDD所有的程式碼實現模型中，領域物件 涉及的程式碼結構最為複雜 ，可以分成 兩個層次 ，如圖1所示。

圖1

可以看到，這裡的 “domain ”代表整個領域物件，而 “model ”則代表領域模型物件，請注意這兩者在命名上的區別 ， 以及它們之間的從屬關係。領域物件是DDD程式碼實現模型的基礎，包含核心業務邏輯的實現。

▶︎   應用服務程式碼實現模型

類似地，針對應用服務，我們通常使用“application”來命名頂層包結構。應用服務包含查詢服務和命令服務這兩大類，所以在子包的命名上，也會用“commandservice”和“queryservice”加以區分，如圖2所示。

圖2

顯然，命令服務和查詢服務，分別依賴於領域物件程式碼實現模型中的命令物件和查詢物件，我們用虛線表示這層依賴關係。在DDD的程式碼實現模型中， 應用服務可以說是互動關係最為複雜的一個程式碼 模型。

一方面，它需要將命令和查詢操作，分派給聚合物件等領域模型物件。

另一方面，它也需要分別和基礎設施，以及其他限界上下文進行互動。

關於後者，我們在討論到案例分析時，還會做進一步展開。

▶︎   基礎設施程式碼實現模型

其實，所謂的基礎設施，指的是DDD應用程式中所使用到的各種具 體技術、工具和框架。常見的基礎設施類元件主要包括這幾個方面：

因此，基礎設施的包結構 並不是固定的 ，而是根據具體的技術開發要求進行靈活的組織，這裡給出一個常見的包結構，如圖3所示。針對基礎設施，我們使用了“infrastructure”，對這一包結構進行命名。

圖3

上圖中 有一點需要注意 ，代表資料持久化的“persistence”包，和代表訊息通訊的“messaging”包，在基礎設施程式碼實現模型中是最常見的，因為它們分別對應著領域物件中的資源庫和領域事件。

在DDD中，資源庫和領域事件的定義位於領域物件程式碼實現模型中，它們與具體的實現技術無關。而與具體實現技術相關的持久化和訊息通訊，則位於基礎設施程式碼實現模型中。這裡體現了 領域物件與實現技術相互分離的設計原則。

▶︎   上下文整合程式碼實現模型

最後，我們來討論上下文整合程式碼實現模型。 需要注意的是 ，這個 模型實現起來難度最大 ，因為涉及到多種系統整合技術體系。

針對這一程式碼實現模型，我們首先需要明確它是面向多個限界上下文的，所以我們需要考慮資料的流向，也就是所謂的 內向（Inbound）資料和外向（Outbound）資料。

一方面，限界上下文，需要暴露訪問入口供其他上下文進行使用。站在當前上下文角度看，這是一個Inbound操作。而當某一個上下 文向外部上下文發起請求時，這就是一個Outbound操作，如圖4所示。

圖4

在程式碼實現模型的設計上，我們也將採用“inbound”和“outbound”來命名包結構。那麼 這兩個包結構下，應該包含哪些技術元件呢？

我們先來討論“outbound”包結構，如圖5所示。 圖中，“rest”包中的REST API將外部請求，轉化為內部的Command和Query物件，並交由應用服務進行處理。在這個轉化 過程中，通常需要引入專門的DTO（Data Transfer Object，資料傳輸物件）物件，和組裝器（Assembler）物件。

圖5

同時，“eventpublisher”包中的 事件釋出器 （Event Publisher） ，則用來面向外部限界上下文釋出領域事件。

接著，我們討論“inbound”包結構。在一個限界上下文中，資料的Inbound操作主要有兩類，一類是 防腐層（Anti-Corruption Layer，ACL） ，用來向遠端REST API發起請求並獲取結果。另一類 是用來完成對領域事件進行響應的 事件處理器（Event Handler） ，如圖6所示。

圖6

基於上下文整合過程，兩個上下文中的“inbound”和“outbound”包結構中所包含的技術元件，實際上是一一對應的，如圖7所示。

可以看到，一個限界上下文“inbound”中的“acl”和“eventhandler”，分別對應著另一個限界上下文“outb ound”中的“rest”和“eventpublisher”。

圖7

至此，關於DDD中四大類程式碼實現模型，已介紹完。在接下來的內容中，我們將 基於一個具體的應用場景，透過案例分析，將這些程式碼實現模型付諸於實踐。基於這個案例，你可以將本文前面介紹的所有內容，和日常開發過程聯絡起來，進一步掌握將模型轉化為具體程式碼的實現方法和技巧。

在現實世界中，工單處理是一個非常常見的業務需求。而工單的發起，通常都是因為使用者需要對訂單進行諮詢或投訴。

在這個場景中，基於DDD的設計方法，我們可以分別拆分出 工單（Ticket）、客服（Staff），以及訂單（Order） 這三個限界上下文。在這三個上下文中，Ticket上下文，會分別與Staff和Order這兩個上下文進行整合，從而建立工單申請，如圖8所示。

請注意，圖中展示了Ticket上下文，所具備的兩種不同的上下文整合方 式。

針對Staff上下文，Ticket上下文將使用REST API，完成對工單中客服資料的獲取。

而針對Order上下文，則使用了領域事件，即一旦Order的狀態發生變化，Order上下文會傳送對應的領域事件到Ticket上下文中。

圖8

在Staff上下文，我們需要完成對上述REST API的構建，它的程式碼工程結構如下圖所示。

可以看到，相較Ticket上下文，Staff上下文的程式碼結構比較簡單，因為該上下文只需要提供對外的“outbound”包，而基礎設施部分也只需要完成對領域物件的持久化操作即可。

圖13

最後，我們來到Order限界上下文，它的程式碼實現模型是這樣的，可以一同看下。

圖14

我們知道Order上下文，提供了針對Order資料的領域事件釋出機制，所以它的“outbound”包中包含了用於釋出領域事件的“eventpublisher”子包，並提供了一個OrderEventPublisherS ervice，如下所示。 

圖15

這裡透過Spring Cloud Stream，實現了領域事件的釋出。而在Ticket上下文 中，我們同樣可以基於Spring Cloud Stream，實現對該領域事件的監聽和消費，示例程式碼如下所示。

圖16

請注意，上述OrderUpdatedEventHandler，位於Ticket上下文“inbound”包的”eventhandler”子包中。

關於這些具體實現程式碼的講解不是本文的重點，你可以參考筆者在Github上的案例程式碼進行系統學習：https://github.com/tianminzheng/customer-service。