2018年6月26日，我很幸運地被DDD巴黎團隊邀請與一些DDD明星同台演講，如Mathias Verraes，Yves Reynhout和Eric Evans，他是設計驅動設計書籍的作者。這次所有的會議都很棒。

最後的討論小組對DDD和我們作為開發人員的工作充滿洞察力。我強烈建議花些時間去看他們（這裡的視頻），這隻有20分鐘，像我這樣的法語演示用英文字幕！

在我的演講中，我談到了「Guerrilla DDD」。這個術語來自我團隊的Scrum回顧展中的討論，並受到UX領域的啟發，設計師面臨著無法正常工作的困難，開始談論游擊隊或「如何破解組織工作」 「（見本書）。

為什麼使用領域驅動設計？

這個詞是埃里克埃文斯在他的同名書中創造的。

使用維基百科的優秀定義是：

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

DDD的最大優點之一是它促使開發人員（以及整個IT團隊）持續改進他們的工作方式。

通過將自己融入思維模式，他們將花時間真正了解他們正在研究的領域（即業務）。他們將在代碼中明確且清晰地預測（作為建模）業務領域，使其幾乎可被業務人員閱讀。

事實上，是的，對於那些還沒有這種心態的開發人員來說，這是DDD的最大優勢。在您發現許多軟體開發環境的嚴酷現實之前：

我們稱之為業務人員，即業務分析師或產品所有者，並不真正掌握他們被分配到的領域相關知識。

在遺留軟體環境中非常明顯。很多時候，他們真的不知道如何在這些凌亂的代碼中實現業務規則。當他們發生可怕的「我們將查看文檔」時，你知道你將有一個漫長而艱難的旅程。當然，我們談論的是「遺留」應用程序，因此沒有BDD或DDD實踐來幫助我們重新創建業務知識。

在其他情況下，他們真正掌握的是業務在遺留舊應用程序中的預測。他們就是Alberto Brandolini所說的Dungeon Master，「他的專業知識是從現有系統的複雜性中建立起來的」。

這種情況的最大問題是遺留的、舊的預測很少代表真正的業務領域。

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

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

收回控制權

我將給出一個真實的例子來更好地理解問題是什麼，如何重新獲得控制並將真正的業務領域放回產品和代碼中。

我們的團隊正在重新設計國際投資銀行的舊應用程序。該領域主要是複雜融資請求的審批流程。審批流程需要支持不同用戶的分析和決策。

第一個重要功能是創建一個任務管理系統（想想待辦事項列表），以幫助他們查看要處理或跟進的請求。此任務管理主要是為了表明團隊可以快速為舊應用程序周圍的用戶帶來價值。我們必須檢索舊遺留資料庫中的請求和決定，這是真正的主要來源。

為此，有兩種情況：用戶要麼是主動加入團隊，要麼被團隊邀請。對於後者，我們發現了令人不安的事情：一些用戶被要求分配到多個團隊......最多10個......使得任務管理系統對這些用戶幾乎無用。

在這一點上，大多數開發人員將接受這個事實並實現這一需求，而不是眨眼:(

當然，業務要求我們這樣做！他們還將繼續添加變通方法和怪癖，以使整個事情可用，但同時，迅速增加代碼庫的意外複雜性。

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

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

在我們的案例中，花一個小時與應用程序的用戶進行討論是一次神奇的體驗，因為他解釋了為什麼許多用戶被分配到多個團隊。

在他們的日常活動中，每個團隊都是一組用戶，每個團隊主要代表一個部門。在遺留應用程序的生命周期開始時，創建了新的一組團隊，每個新團隊都與原來特定部門相關聯。

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

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

實際上是這樣：

我們發現的是以前提出的功能性債務的概念。

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

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

幸運的是，開發團隊足夠強大，能夠讓每個人都了解在應用程序中設計團隊的必要性，以及業務團隊日常工作的方式。

最後，我們創建的設計現在接近於此：簡單且更好地將業務投影到代碼中。

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

結論

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

作者：JDON

原文：https://www.jdon.com/51439

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