在關於DDD的每本書和每次會議中，我都聽到「DDD不是銀彈」。我可能是唯一一個反思的人。因此我可能會錯過一些東西。

不過，自從我開始學習DDD以來，我就在每個項目中使用它。即使在CRUD實現足夠好的簡單情況下也是如此。

因為了解我的領域名並能決定CRUD是否能足夠好地實現。

在可能的情況下進行一到兩次事件風暴會議。我嘗試了解子域，看看它們是如何與我的有界上下文對齊的。我知道核心領域的知識。這是DDD的戰略模式對於幫助我理解上下文至關重要，以便決定是否適合應用DDD。

當你不需要它時你需要它

我需要DDD戰略模式來深入了解一個領域，以決定DDD戰術模式是否與其相關並可應用？如果有的話。換句話說：戰略模式對於理解任何領域都很有用，而戰術模式可能與您的業務上下文不太相關。

CQRS絕對不是銀彈，事件溯源，存儲庫，實體或價值對象也不是。但DDD在其戰略方面（領域分析，有界上下文等）一直非常有用。

但有時你卻不使用它。

正如Liz Keogh 在DDD Europe 2016上的出色解釋。她對Cynefin框架進行了精彩的討論。當您處於框架的混亂區域時，甚至可能無法使用戰略模式或任何其他工具來分析業務，因為任何分析都是不可能的。你先行動，然後感覺並做出反應。

但作為一名顧問，在這樣一個混亂的環境中，我從來沒有被召喚過，或者我從未認識到它。我通常被稱為在遺留系統上工作，這些遺留系統由過多的技術重點和很少的域分析構成，所有這些都在複雜的業務領域。每次DDD戰略模式都能幫助我更快地做出更好的診斷。

DDD定位應該在哪裡？

即使在項目的實施方面，DDD也有很多有用的東西。它並不總是關於CRUD或CQRS和事件採購。但它總是根據領域語言泛在語言命名方法，類，介面和模塊。這是DDD。

如果我鼓勵技術專家和領域專家之間的合作並反覆工作以完善概念模型，我可以聲稱我正在做DDD。

如果感謝這種緊密的合作，我們可以很早發現我們想要構建的軟體對業務並不重要，我仍然可以說我正在做DDD。它可以為公司節省資金，例如通過選擇通用的現成解決方案，或者決定構建快速CRUD解決方案。

DDD是一種甚至可以幫助您確定何時不需要它的方法，這是DDD悖論。這反而使得它非常普遍。一種普遍的方法對我來說似乎是一顆銀彈。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！