Jan. 04 23:14~Jan. 05 00:12
▲照片與內文無關XD
問題
去年（2020）在上【領域驅動設計與簡潔架構入門實作班】有學員問Teddy：「有沒有什麼情況不要套用領域驅動設計（Domain-Driven Design；DDD）？」
***
問題領域
從問題領域（Problem Domain）的角度來看，Teddy認為以下幾種狀況明顯不適用：
- 問題過於簡單：DDD藍皮書《Domain-Driven Design: Tackling Complexity in the Heart of Software》的副標題已經說明，這是一種解決軟體複雜性的方法，因此如果你要處理的問題很簡單，就不需要動用到DDD。問題是:「你怎麼知道你的問題是屬於簡單或是複雜的問題？」Teddy有兩種判斷的方法：
- 一個Bounded Context就可以解決：如果你的問題不需要切成好幾的Bounded Contexts就可以解決，通常代表這個問題比較單純，也許用傳統OOAD方式來處理就可以。
- 屬於Cynefin framework裡面的simple problem：Cynefin framework是敏捷開發經常引用的一個框架，它將問題分成四種—Simple、Complicated、Complex、Chaotic，如果你的問題屬於Simple類型，也就是事情的因果關係非常清楚，那麼有很大的機會不需要動用到DDD就可以把問題解決。
- 問題夠複雜但屬於非核心領域（Core Domain）：有時候你的問題很大且複雜，但是你負責的Bounded Context不是系統的核心，只是Generic Subdomain，例如權限管理。在這種情況下，就不需要堅持一定要使用DDD。
- 缺少領域專家配合：DDD強調開發團隊與領域專家密切合作，如此才能建立合適的領域模型與通用語言。如果你的專案缺少領域專家的密切配合，很難發揮DDD的最大藥效。
- 查詢功能：依據CQRS的做法，只有在Command端（會修改系統狀態的使用案例）才需要套用DDD。如果是不會改變系統狀態的Query（查詢功能），則不需要設計領域物件，直接從資料庫「生出」前端所需的Read Model或稱為View Model即可。因為查詢不需要領域物件，因此也就不會使用到DDD。
***
解決方案領域
從解決方案領域（Solution Domain）的角度來看，Teddy認為以下幾種狀況代表團隊的技術還不成熟，也許需要練功一下，或是找技術專家一起配合開發，否則斷然在專案上採用DDD，可能會採不少雷且只有「事倍功0.1」的產出：
- 不懂如何建立領域模型：DDD的一個重點就是透過領域模型作為通用語言的骨幹，這個領域模型可以是物件導向模型、函數模式或程序模型，但一般比較常見的還是物件導向模型。以物件導向模型為例，既使在台灣業界，不少程式設計師最熟悉的還是資料模型，或是透過使用者介面來塑模領域物件，這樣做出來的領域物件，應該是很難達到Ubiquitous Language in Code的標準。
- 沒寫自動化單元測試：在建立領域模型與達到Ubiquitous Language in Code的旅程上，經常需要不斷調整領域模型，甚至Bounded Context的邊界也可能會略作調整。在這種情況下，如果沒有自動化單元測試（use case level與method level的單元測試）作為安全網，很難在一定的成本之下持續精進領域模型。
***
代價
引入任何新的方法，都有適合與不適合的Context，以及相對應要付出的代價。Teddy認為DDD整套用下來，的確可以達到「讓軟體變軟」的最終目的，但學習門檻還是有的。
在「讓軟體看起來可以動就好」以及「讓軟體變軟」之間，還有很大的取捨空間。要不要用DDD，要怎麼用，還是要看公司、專案、團隊的特性再來決定，不要只聽別人說好棒棒就搶著用。體質不好，可能虛不受補，藥吃多了身體也不見得會有起色。
***
友藏內心獨白：我覺得好的東西你不一定會喜歡啊。
沒有留言:
張貼留言