DDD游擊隊 - yannick grenzinger

為什麼使用領域驅動設計？
這個詞是埃裡克埃文斯在他的同名書中創造的。
使用維基百科的優秀定義是：

• 將專案的主要重點放在核心領域和域邏輯上
• 基於領域模型的複雜設計
• 啟動技術專家和領域專家之間的創造性協作，以迭代方式完善解決特定領域問題的概念模型。

在某些時候，業務領域將自己與一個糟糕的應用程式對齊，我稱之為功能性債務，這比技術債務更糟糕。

此外，這並不是因為這些人不夠聰明，而是因為有許多心理偏見推動這個方向，如“ 達克效應（無知的人總是自以為聰明） ”或大多數“ WYSIATI 所見即所有 ”。

收回控制權
我將給出一個真實的例子來更好地理解問題是什麼，如何重新獲得控制並將真正的業務領域放回產品和程式碼中。
我們的團隊正在重新設計國際投資銀行的舊應用程式。該領域主要是複雜融資請求的審批流程。審批流程需要支援不同使用者的分析和決策。
第一個重要功能是建立一個任務管理系統（想想待辦事項列表），以幫助他們檢視要處理或跟進的請求。此任務管理主要是為了表明團隊可以快速為舊應用程式周圍的使用者帶來價值。我們必須檢索舊遺留資料庫中的請求和決定，這是真正的主要來源。
為此，有兩種情況：使用者要麼是主動加入團隊，要麼被團隊邀請。對於後者，我們發現了令人不安的事情：一些使用者被要求分配到多個團隊......最多10個......使得任務管理系統對這些使用者幾乎無用。
在這一點上，大多數開發人員將接受這個事實並實現這一需求，而不是眨眼:(
當然，業務要求我們這樣做！他們還將繼續新增變通方法和怪癖，以使整個事情可用，但同時，迅速增加程式碼庫的意外複雜性。

在這一點上，DDD經歷了真理的考驗。為了兌現DDD的承諾，你必須說“不”並推動組織改變。

首先，盡一切可能看到真正的使用者。

在我們的案例中，花一個小時與應用程式的使用者進行討論是一次神奇的體驗，因為他解釋了為什麼許多使用者被分配到多個團隊。
在他們的日常活動中，每個團隊都是一組使用者，每個團隊主要代表一個部門。在遺留應用程式的生命週期開始時，建立了新的一組團隊，每個新團隊都與原來特定部門相關聯。

然而，修改團隊是如此困難，以至於每次使用者需要關注新的法律實體或者公司在團隊之間重新分配時（因為內部重組），選擇將使用者新增到另一個團隊。也許程式碼庫已經不夠靈活，或者企業不想投資這種能力。

最後應該是簡單的，如下圖所示:

實際上是這樣：

我們發現的是以前提出的功能性債務的概念。
在開發團隊中，我們強烈反對這一點，業務代表正在努力保留遺留應用程式中實現的內容，主要是因為他們已經習慣了它並且他們害怕創造新的東西。

我們不得不多次解釋功能性債務使專案處於危險之中，意外的複雜性，潛在的錯誤和可用性問題。​​​​​​​

幸運的是，開發團隊足夠強大，能夠讓每個人都瞭解在應用程式中設計團隊的必要性，以及業務團隊日常工作的方式。
最後，我們建立的設計現在接近於此：簡單且更好地將業務投影到程式碼中。

游擊隊開發團隊最終獲勝，並有其快樂的結局故事。

結論
在某些情況下，要真正做DDD，您將不得不在遺留應用程式中分解原來組織結構，錯誤的組織結構對業務的錯誤投射影響，您將不得不進入游擊隊方式去改變它們。