DDD社群權威解讀：2020年之領域驅動設計 - ziobrando

DDD定義
領域驅動設計DDD是一種用於高複雜度高價值企業軟體的軟體開發方法。
它不是體系結構或方法論。這是一種更全面的方法，跨社會技術堆疊的不同層：從閱讀業務需求和組織約束到良好的編碼實踐。
多年來，實踐和工具不斷髮展，但大多數核心概念仍然存在。

關鍵特徵

• 策略已嵌入到方法中：它不是一種適用於所有方法的單一規範。
• 專注於學習：這是交付高價值軟體的主要障礙，所以讓我們將其作為我們方法的核心。
• 語言（banq注：英語等自然語言）是軟體開發領域的一等公民。
• 多個模型是不演變為泥濘球的關鍵。
• 複雜的架構選擇至關重要。如果您僅想到CRUD，那麼您還有很長的路要走。
• 期望良好的編碼實踐。沒有經過嚴格測試的進化軟體會導致自殺。

戰略
並非大型系統的每個部分都需要複雜的方法。如果將DDD的許多功能應用在錯誤的位置，則可能會過大。但是，無論如何，檢測當前的業務需求，瞭解形勢並制定明智的策略都是一件好事。
DDD建議將重點放在核心域（即該域當前狀態下的高價值部分）上，而對其他部分（如支援子域和通用子域）則退回到更保守的方法。

大圖戰略性事件風暴可以成為了解組織當前策略和需求並檢測其當前核心的強大工具。
繪製上下文對映可以幫助解讀戰略上的侷限性和成功專案的障礙，否則會浪費大量資金在一開始就註定要失敗的專案中。(banq注：條條大路羅馬，首先把羅馬方向確定，在南面還是北面，否則南轅北轍)

專注於學習
DDD就是要學習領域的內在複雜性，提煉為有效軟體構建模型所需的知識。在專案結束時，DDD從業人員很難與領域專家區分開。
如果學習是瓶頸，那麼我們應該得出後果，並停止嘗試針對可預測的交付進行最佳化，而是開始針對有效的學習進行最佳化。
Whirlpool漩渦模型是一種描述“過程”的方法，該過程不是順序的，並且主要由可用反饋的質量決定。
在此問題空間中出現了諸如EventStorming，Domain Storytelling和Event Modeling之類的協作建模實踐，從而彌補了傳統需求收集無法提供的學習差距。
演進軟體是我們正在努力的。高度的領域複雜性意味著我們無法一口氣學習所有內容，這是由於我們對複雜領域的學習限制所致：我們可以馬上理解財務嗎？或因為域本身在不斷髮展。我們最初編寫軟體的嘗試將是一個合理的近似值，但是我們必須重寫才能使事情正確。
諸如Mob程式設計之類的協作編碼方法在DDD空間中越來越受歡迎。

偶然的複雜性
如果學習是最難管理的資源，那麼避免學習不必要的複雜性對於任何成功的團隊都是至關重要的。
有界上下文有助於定位複雜性，避免了很多複雜情況，您還應該意識到...
無處不在的語言將封裝本地理解，因此沒有人需要記住...

專注語言
無處不在的語言是DDD中的原始概念。它描述了參與專案的每個人所講的無歧義語言。但是，口語只能由字典部分定義。在DDD中，語言已成為確定我們實施模型質量的工具：翻譯和誤解是意外複雜性不斷攀升的指標，而有邊界上下文中無處不在的語言的出現則標誌著團隊學習的進展。
重構以獲得更深刻的見識是一種反映團隊學習到程式碼的方法。可讀且意圖公開的程式碼最終將成為一種使用更精確的對話語言的程式碼。
這種語言的形式在過去幾年中不斷髮展：儘管最初主要是對名詞進行強調，但隨著時間的流逝，更復雜的事件驅動型語言出現了，領域事件是業務敘事和業務描述及其軟體實施基礎。
領域事件在語義上比名詞更精確，並且它們觸發軟體和組織中的反應。EventStorming再次幫助使軟體語言接近於業務語言，這比資料更具說故事性。

多種模型
企業問題沒有單一模型作為解決方案。在DDD中，“有界上下文”的概念捕捉到了為更好的利益而協作的多個本地專用模型的概念。
不同的模型僅出於一種目的進行了最佳化，並且可以在內部應用不同的範例。因此，您將擁有一個EventSourced繫結上下文，以及一個更簡單/更便宜的CRUD，例如在另一個BC中的實現。
上下文對映有助於視覺化所涉及的不同模型的邊界和目的，而“邊界上下文畫布”可以很好地幫助您討論並快速記錄任何給定邊界上下文的邊界和目的。
通常在反腐敗層的支援下，在有界上下文中執行模型分離也可以提供更安全的開發空間。共享資源通常是對健康發展的威脅。
也就是說，人們不會重新命名共享資料庫中的概念，也不會完全重構概念，因為他們可能擔心破壞在共享永續性上執行的其他實現。一個私人的永續性支援，允許更安全的程式碼演變更多的機會，同時保持其中明確約定合同更安全。

架構
在早期，DDD似乎是一種體系結構。在藍皮書中，描述了一種體系結構方法（描述了諸如聚集，實體，價值物件，儲存庫等的戰術模式），不幸的是，它不只是那樣。
真實的故事是，DDD需要強大的體系結構基礎才能交付演進軟體，而在Domain Model之上的一系列模式書中提出的體系結構是2004年唯一可行的選擇。
現在，情況變得更加多樣化，並提供了更多選擇：

• 以Domain Events作為一等公民的更復雜的OO方法，請參閱Vaughn Vernon的實現域驅動設計
• CQRS / ES中單獨或經常結合使用的命令查詢職責隔離和事件來源
• 函式式語言，請參閱Scott Wlaschin的“ 域建模使函式式化”。
• Actor模型是實現複雜的，事件驅動的域模型的另一種巧妙方法，請參閱Vaughn Vernon的Actor模型的Reactive訊息傳遞模式。

供應商獨立性
這是一個經常被忽視的價值，但絕對存在。由於DDD處理企業軟體的高價值部分，因此至關重要的是，您的組織必須控制其軟體資產。
核心域的實現需要獨立於供應商技術，無論是框架，中介軟體還是資料庫。您的業​​務邏輯應該隨著業務的發展而發展，而不是其他任何事情。
順便說一句，供應商獨立性一直是DDD壽命的關鍵因素之一。沒有“ DDD框架”之類的東西。SOA開始時是一套合理的原則，然後在供應商工具的重壓下崩潰，變得貪婪並劫持了架構選擇。

微服務
微服務社群之間存在很多融合，這是因為“繫結上下文”概念非常適合檢測理想的服務粒度，並且由於“事件驅動”已成為非同步實現和更好地描述業務語言的成功範例。
有關本文的更多資訊。

良好的編碼習慣
不斷髮展的程式碼庫要求安全。只有當我們控制系統的行為時，才能實現安全。假設前提控制了我們的上下文邊界（banq注：特斯拉馬斯克的第一性原理，公理是定理的前提，任何真理都是有假設前提的，除了這一句，這句是一個絕對真理之外，沒有其他絕對真理了。），因此，必須使用有界上下文Bounded Contexts-這個概念並且進行足夠的測試以確保我們的程式碼庫安全。
儘管不是強制性的教條-DDD並未規定100％的程式碼覆蓋率-DDD假定具有編寫高質量程式碼和進行高質量測試的能力。
駭客和捷徑-通常不建議您使用駭客和捷徑，特別是那些建立鎖定到平臺和工具的工具。關注點分離也是實現級別的強大驅動力。

開發運維
DevOps運動的發展很大程度上獨立於DDD，但到2020年，頻繁且可靠的部署將加速任何反饋週期，因此就順其自然。
BDD：行為驅動開發是另一種軟體開發方法，它試圖縮小軟體與業務之間的差距。不同的工具，非常相似的心態以及非常緊密的社群。
行為驅動開發強調示例的作用，以瞭解業務期望的真實本質，而DDD則完全同意！

總結
加入該社群15年之後，我不得不承認，我對官方定義仍然不完全滿意。也許我在看錯東西。
如果我真的認為2020年的領域驅動設計可能是軟體開發中最有趣，最開放的社群之一，那麼它可以深入討論技術主題及其對組織文化水平的影響。開放性，好奇心，精通性和完整性使這個社群變得很酷，而領域驅動設計對於任何戰略性業務軟體開發專案而言都是越來越有價值的工具。

banq注：文中一個觀點不敢苟同，DomainEvent領域事件是與事件驅動架構EDA、EventSourcing或Actor模型等技術實現架構無關，是有關業務領域事件，其中存在Alberto Brandolini因為人情關係的推銷左右。DDD社群也是一個DDD江湖，出頭早的帶出頭晚的，儘管晚輩後浪才是真正專家，但是後浪還是不會忘記前浪的伯樂之恩。