領域驅動設計學習筆記（16）：領域模型要放什麼東西？

Jan. 19 10:00~11:07

客人的問題

上周末在【領域驅動設計與簡潔架構入門實作班】有學員問Teddy…

學員：DDD的building blocks包含Entity、Value Object、Aggregate、Service、Repository、Factory等，為什麼你的domain model裡面沒有畫出Repository？

Teddy：為什麼要在domain model畫Repository？

學員：因為我們要「派工」啊。

Teddy：派工 ？！

學員：對啊，我們要畫設計圖，然後派工給工程師去寫程式。

***

領域模型作為瞭解問題的工具

領域驅動設計是透過「建立領域模型」來驅動整個軟體開發設計的方法。模型屬於solution domain，如果採用最常見的物件導向分析設計方法，領域模型的主角就是代表問題領域裡面重要概念的「物件」。

例如，開發看板系統，在「看板系統」這個問題領域中，重要的概念包含Kanban Board、Workflow、Stage、Swimlane、Kanban Card、WIP Limit、Flow、Lead Time等，它們自然成為領域模型的當然候選人。

你在跟看板的領域專家討論問題時，會出現Repository或Factory這種概念嗎？應該不會吧！所以，你不會在領域模型看到它們。

***

但是我要派工啊

好、好、好，Teddy知道你要派工。領域模型首先作為了解問題領域的分析工具，最後當然還是要用程式碼實作出來。傳統OOAD透過「模型轉換」過程，將分析模型轉成設計模型再轉成實作模型。但DDD希望針對同一個bounded context，整個開發過程就只有一個模型，用這個模型作為領域專家與團隊的通用語言（ubiquitous language），最後再將通用語言用程式碼實作出來，達到ubiquitous language in code的境界。

想要將DDD的領域模型再轉成詳盡的設計模型然後拿給程式設計師去寫程式（完成一個派工的動作XD），是waterfall的做法。如果號稱使用DDD但還是採用這種做法，代表團隊根本沒有共通語言，所以才需要使用另一種語言（派工文件）來溝通。

看到領域模型中的Aggregate，自然就知道需要搭配一個Repository來負擔持久化（把Aggregate狀態存到資料庫中）的責任，根本不需要在領域模型裡面表達這種關係。

***

DDD為什麼流行？

DDD藍皮書2004年出版至今也過了10幾年，為什麼近幾年才流行？Teddy認為除了很多人想透過DDD來開發微服務系統以外，另一個原因就是DDD、Event Storming與Clean Architecture、TDD這些做法全部加起來，非常適合用來作為落實敏捷開發的一種實踐方法，符合目前整個軟體開發的主流做法，做得好可以讓你的軟體變軟。

軟體變軟，才能夠支撐公司業務變得更敏捷（靈活）。DDD是domain-driven design，不要搞成document-driven design。

***

友藏內心獨白：軟體開發的特性就是「按圖施工，保證不成功。」