為什麼DDD難以教授？

DDD要旨
DDD旨在解決軟體核心領域的複雜性問題。這意味著，在理想的世界中，您的軟體必須與其解決的問題一樣複雜。此外，您解決的問題必須是貴公司最有價值的事情。DDD提供瞭解決這些問題的模式（。實現DDD就是分析依賴關係。

戰術模式
戰術模式是我們開發人員最具體的部分，因為它是關於程式碼的！這是一套技術工具，可以在最重要的地方具體應用DDD方法。這些模式以與良好實踐相同的速度快速發展。一個眾所周知的例子是儲存庫模式。戰術模式有助於瞭解如何構建業務的每個部分。

戰略模式
戰略模式更抽象。它們允許將域（業務）分類為子域，以便了解如何圍繞它構建應用程式的上下文。每個上下文都有一個特定的通用業務語言（無處不在的語言），並使用精確的通訊方式。上下文是否將一些事情強加給另一個上下文？他們共享核心嗎？他們如何溝通？所有這些都可以使用戰略模式捕獲。它們有助於瞭解業務的不同部分以及它們如何相互作用。

DDD通常存在問題
自從我在2012年開始研究DDD以來，我遇到了兩個經常出現的問題。首先是新人（包括我）不知道從哪裡開始。他們覺得DDD很大，但參考書很嚇人。這些聰明人社群中使用你以前從未聽過的單詞似乎很好，但你覺得處在他們周圍卻很愚蠢，自己很難在這個社群留下來。
第二個是大多數人（也包括我）乍一看不會抓住戰略與戰術模式的二元性。更糟糕的是，他們可能會專注於戰術模式，因為它們看起來更具體。我們已經瞭解其中一些，如工廠或分層架構。結果可能是我們忽略了戰略模式。

根本原因分析
在我的DDD教學領域，我認為有兩個子領域：一個是戰術，另一個是戰略。
教授DDD的有效實施將為戰略模式繪製一個有界的上下文，為戰術模式繪製一個上下文。我們有幾個原因來證明這種實現的合理性。

第一條：不同的語言。這兩種語境具有特定的無處不在的語言。
第二條：不同的生命週期。戰術模式迅速發展。來自藍皮書大部分模式可以用更新的模式替換，如CQRS / ES或六邊形體系結構。戰略模式更加持久。
第三條：兩種情況下的抽象級別都不盡相同。
最後：戰略上下文更為重要。這是我的核心領域，是我在教授DDD時想要分享的核心價值觀。我的上下文之間存在明顯的依賴關係。戰術模式很重要，但如果我單獨教他們帶來價值不大。

現在有聊“為什麼DDD難以教授”答案的一部分：它混合了兩個非常不同的背景。兩者都很有用，一個比另一個更重要，但也更抽象，因此更難理解。

解決方案嘗試
DDD作者Eric在改善行業，提供戰略和戰術觀點方面確實雄心勃勃。我認為世界各地主要DDD會議的趨勢和出現證明了他的成功。我也理解他願意提供一些不太抽象的東西，以避免架構師患上象牙塔綜合症。
不過，戰略和戰術模式實際上是不同的野獸。DDD兩面性讓人難以理解。
我們如何管理這種複雜性？這取決於上下文。但是在為新手教授DDD的領域，我會強調戰略模式，主要是有界的上下文，因為這是可以導致所有其他模式的模式。然後我會解釋所有行業標準的良好實踐（持續整合，責任分離等等）都是實施核心領域的必要條件，DDD也將其命名為戰術模式。如果試圖反過來（將教導戰術部分作為DDD的重點介紹）會增加了錯過核心概念的風險。
​​​​​​​