解決DDD核心的複雜性

核心領域：無所不在的語言
在“領域驅動設計：解決軟體核心中的複雜性”（藍皮書）中，Eric Evans認為領域專家和軟體開發團隊之間的不良協作導致許多開發工作失敗。DDD旨在透過彌合這種協作和溝通差距來提高成功率。
為了能夠流暢地分享知識，DDD呼籲培養一種共享的，面向商業的語言：無所不在的語言。此語言應類似於業務域及其術語，實體和流程。
無處不在的語言應該在整個專案中廣泛使用。所有溝通都應該在無所不在的語言中進行。所有檔案都應在其中制定。甚至程式碼也應該“說出”無所不在的語言。
許多方法都在努力降低風險並提高軟體專案的成功率，但由於Ubiquitous Language統一語言是DDD實現它的手段，我認為它是域驅動設計的核心領域。
定義無所不在的語言並不是一件容易的事。由於軟體不能很好地應對歧義，因此每個泛在語言術語應該只具有一個含義。不幸的是，這不是人類語言的工作方式 - 通常語言在不同的語境中具有不同的含義。為克服這一障礙並支援培養嚴謹語言的過程，採用了另一種DDD模式：有界上下文。

支援子域：有界上下文
為了防止術語具有多重含義，DDD要求每種語言都具有嚴格的適用性上下文，稱為有界上下文。這種模式定義了一個邊界，在其中可以自由使用泛在語言。除此之外，語言的術語可能有不同的含義。
雖然有界上下文模式是領域驅動設計的重要組成部分，但我認為它是一個支援子域，因為它的目的是支援無處不在的語言 - 核心域的形成。
正如我之前提到的，程式碼還應該“說出”實現它的有界上下文的無處不在的語言。但是，如何在程式碼中實現業務域？實現業務領域沒有一刀切的模式。有多種選擇，這是我們的下一站。警告：神聖的奶牛即將受到傷害......

通用子域：領域實現
這些模式提供了實現業務域邏輯的不同方法：

1. 事務指令碼
2. 活躍記錄
3. 領域模型
4. 事件源領域模型

1.降低複雜性
DDD與戰術建模模式的脫鉤將防止許多新人經歷的許多誤解和困難 ，一旦DDD與戰術建模模式分離，它就不再需要任何程式碼樣本。它是一種純系統建模方法，可應用於任何技術堆疊和任何軟體範例。

2.更廣泛的適用性
我非常不同意領域驅動設計應該只應用於複雜專案的觀點。這一概念是由DDD與領域模型模式的強耦合驅動的。一旦我們打破這種耦合，就會開啟一個全新的可能性世界。

溝通：
無論業務領域多麼簡單，如果團隊成員對相同的工件使用不同的術語，遲早他們會發現自己處於意外複雜的境界。無所不在的語言模式阻止了這種情況，並在所有團隊成員之間產生了清晰的溝通媒介。

業務增長：
領域的複雜性增加的頻率高於其複雜性降低的領域。對於所謂的非複雜專案，這種增加的可能性最高。一旦發生這種情況，應重新考慮實施模式決策並使其適應新的複雜性級別。

3.微服務
如今，微服務炙手可熱。擴充套件DDD對更多專案型別的適用性將允許許多基於微服務的解決方案利用寶貴的DDD工具。有界上下文模式提供了一種將系統劃分為一組獨立服務的業務驅動方式，而結構對映是對映服務的拓撲和它們之間的互動模式的好方法。

“你瘋了嗎？”
我不認為我的命題 - 從DDD中取出戰術模式 - 就像它最初聽起來一樣瘋狂。回到了歐洲DDD會議2016年，Eric Evans的自己說，在藍皮書中描述的是一種領域模型實現的方式，但許多誤以為它是領域驅動設計的實現方式。
看，戰術建模模式從來沒有打算成為DDD的唯一方式，但很多人都認為它們是這樣的。它們會產生外來噪音，並使注意力從最重要且獨特的DDD特點上移開。
此外，您不能說領域驅動設計方法處於完美狀態，並且沒有理由改變。不幸的是，它的低採用率不言自明。DDD值得更多關注。藍皮書十多年前就出版了，從那時起，這種方法幾乎沒有改變。我相信它應該改變。不是因為它很糟糕 - 恰恰相反，因為它很棒。但它具有比目前實現的更多，更多的潛力。

最後的想法
我決不打算詆譭戰術建模的重要性。恰恰相反：這個主題值得關注得多。但在它自己的背景下。除了領域模型之外，還有更多的模式，以及更多的方法來實現它們，而不是適合單個DDD書籍。而且，即使在非DDD專案中也可以實現這些模式，即使專案中沒有單一的聚合，專案也可以遵循DDD原則。