[還少一本書] Domain-Driven Design Distilled

August 09 07:30~09:37

 

上禮拜五因為要買《Building Microservices》這本書特別跑去天瓏書局逛了一下，在書架上看到《Domain-Driven Design Distilled》（DDDD）這本新書。家中已經有三本DDD（Domain-Driven Design）的書，每本都厚達4~5百頁，買回家之後擺在書架上幾乎沒看。這本不到150頁的《Domain-Driven Design Distilled》看起來容易讀多了，當然要買回家。

原本以為這本書會和它的其它三本「前輩」一樣淪落到擺在書架上的命運，沒想到因為《Building Microservices》提到DDD的具體應用情境，讓Teddy在上週末讀完《Building Microservices》之後在昨天緊接著把《Domain-Driven Design Distilled》看了八成。今天擠不出什麼料就來介紹這本書好了。

***

在開始介紹之前先來一段「無責聲明」，以下所說純屬Teddy目前對於DDD的理解，其中可能包含誤解，大家姑且當做看戲聽聽就好。

聽過物件導向分析設計（OOAD）的鄉民們應該知道，開發軟體的流程可視為一種塑模（Modeling）的過程。問題經過分析之後得到domain model，接著進入設計階段產出design model，再進入實作階段產生implementation model。

Domain-driven design，顧名思義就是以上述的「domain model」為主的一種設計。但DDD和OOAD不一樣的地方之一是DDD希望同一份domain model既是開發人員與領域專家溝通的共通語言，也可以直接對應到程式碼。

一個系統有可能涵蓋數個不同的（sub）domain model，例如進銷存系統就包含了進貨、銷貨、會計、庫存管理、客戶關係管理等領域。用傳統的分析方法，可能會嘗試建立一個很大的domain model來一致性的表達不同（sub）domain之中的概念，以利於團隊成員溝通。但是這麼做其實很困難，因為人的腦袋要一口氣理解為數眾多的概念以及它們之間的關係，其實非常困難。此外，有些概念可能同時出現在不同的（sub）domain但卻有不同的意義。例如，「退貨」對於銷貨領域和會計領域的意義與做法就很可能不一樣。

DDD提出Bounded Context這個概念（這其實是一個pattern，DDD發明者Eric Evans把DDD用pattern的格式來表達），以上面進銷存系統為例，如果把進貨、銷貨、會計、庫存管理、客戶關係管理視為不同的Bounded Context（界限環境、界限上下文），則它們所屬的domain model只需考慮在該Bounded Context的情況即可。

***

▼這個想法其實很簡單，在〈什麼是Pattern（9）：Pattern的胚胎期〉中曾經討論過。如下圖所示，假設大圓圈內的每個黑色員點代表一個概念（concept）或domain object，如果把一整個軟體系統視為一個「大世界」，則在做分析設計的時候所要考慮的概念與關係就變得很複雜。

 

▼如下圖所示，如果可以找出Bounded Context（兩個小圓圈代表兩個Bounded Context），則每一個Bounded Context所要關注的domain model就相對簡單許多。

 

每一個Bounded Context裡面的domain model就成為DDD的另外一個重要pattern的骨幹—Ubiquitous Language（通用語言）。Bounded Context和Ubiquitous Langauge在《Domain-Driven Design Distilled》書中將其比喻為國家和語言。例如法國說法語、英國說英語、德國說德語。每個國家好比一個Bounded Context，該國的語言在這個國家界限之內是通用語言（Ubiquitous Langauge），大家都可以理解這種語言。但是離開這個國家之後，原本的Ubiquitous Langauge在另一個國家就沒有意義（例如在法國人聽不懂德語是正常狀況）。請注意，DDD所說的Ubiquitous Langauge並不是全世界通行（整個專案規模通行）的共通語言，而只是通行於某個特定Bounded Context的「國語」。

***

看到這裡鄉民們可能會說，哪又怎樣？這不就是一種模組化的概念嗎？嗯，廣義來講是這樣沒錯，但故事還沒結束。透過Bounded Context把大問題切成小問題之後（由上而下的設計概念），最後每個小問題解完還是要合併成整體才可以發揮作用。每一個Bounded Context之間的關係必須被探討與管理，才可以讓它們一起合做成為一個整體。DDD透過Context Mapping來表達這個關係。兩個Bounded Context對映關係有很多種，包含Partnership、Shared Kernel、Customer-Supplier、Conformist、Anticorruption Layer、Open Host Service、Published Language、Separate Ways、Big Ball of Mud。這些關係都可以視為一個pattern。

DDD還談到domain model要如何設計。DDD把domain model的元素分成Entity、Aggregate、Value Object、Service等。在《Domain-Driven Design Distilled》書中還提到Domain Event的溝通方式，透過Domain Event可以讓其他人知道某個domain object狀態改變並因此做出回應。

***

透過《Domain-Driven Design Distilled》這本書可以快速理解DDD的重要概念，之後再去讀《Domain-Driven Design》或《Implementing Domain-Driven Design》應該會容易許多。

***

友藏內心獨白：看到pattern就好辦了。