l

2021年1月19日 星期二

領域驅動設計學習筆記(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。

***

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

沒有留言:

張貼留言