OOA/OOD/OOP中，尤其是OOD/OOP，大家都不陌生，用了很多年。並且大部分人，都是從OOP開始，到了一定階段，會再去接觸OOD, 之後是OOA。

這樣用久了，自然而然會覺得“面向物件”是天經地義的，不太會去想面向物件有什麼問題所在。

而DDD裡面，就很明確的指出了面向物件的2個問題，並給出了相應的解決答案。

有興趣朋友可以關注公眾號“架構之道與術”， 獲取最新文章。
或掃描如下二維碼：

問題1：面向物件擅長表達“結構”，不擅長表達“行為”

在面向物件裡面，我們把系統裡面所有東西都表達成物件 + 物件之間的關係，這樣清晰的表達出了系統的“結構”。

但是對於“行為”，也就是“流程”，通常被掩蓋了。比如一個業務流程，它牽扯到好幾個物件，那這個流程，反映在程式碼裡面，就是物件與物件之間的引用和互相呼叫關係，這實際是一種“隱性表達”。雖然你可以畫“互動圖”，但這種互動圖只能停留在設計層面，在程式碼層面，沒有對應物。

所以DDD裡面引入了“領域服務”，單獨把重要的“行為”抽出來進行“顯性”表達。

問題2：面向物件不擅長表達“業務規則”

業務規則，說到底也是種“行為”，而在程式碼裡面，我們通常把業務規則表達成了物件的某個方法。

隨著業務規則的複雜，這個方法也變得越來越難理解。所以設計模式裡面有Strategy模式，對這種場景進行建模。

但設計模式主要偏重從技術角度去談這個問題，DDD呢，把這個特意強調了出來。強調在業務分析的時候，就把“業務規則顯性化”，為此引入了Specification模式。

總結

所以說，DDD其實是面向物件方法論的一個昇華。