DDD返工

摘要： 本文要點 類似領域的兩個獨立專案，都使用DDD實現，這提供了一個有趣的機會，可以從失誤中學習，從而做得更好。 有界上下文沒有用在第一個專案中，因為那需要客戶認同構建更小的系統。 這兩個專案的最大不同是採用有界上下文以及建立一個反腐層。 ...

在ofollow,noindex" target="_blank">Explore DDD 2017大會上，Jimmy Bogard 談到，他們獲得了一個少有的機會，使他們可以在一個專案中進行他所謂的“返工（do-over）”。雖然不是完全從頭開始重寫，但他是參與了相關公司的兩個非常類似的專案。InfoQ採訪了Jimmy，瞭解他們如何運用從第一個專案中獲得的經驗教訓使第二個專案取得更大的成功。

InfoQ：“如果我們可以把一切重新來做……”，這是那些從事大型軟體專案開發的人常說的一句話。那種事後智慧通常可以為將來的專案提供指導。你們獲得了一個少有的機會，可以在幾年內實際從事兩個客戶和領域都幾乎相同的專案。您能介紹下你們的客戶、專案和主要目標嗎？

Jimmy Bogard：終端使用者是德州政府僱員，跨越許多不同的地理邊界。第一個系統是面向青少年的案件管理系統，涉及法律程式的各個方面。這個青少年系統的整體目標不是懲罰，而是為違法的孩子提供幫助。客戶包括州主要都市地區的縣以及一個負責監督每個縣的程式的州屬機關。

第二個系統限制更多一些——為德州的縣檢察部門提供一個僅供他們使用的單一系統，而且僅用於成人程式。

InfoQ：當第一個專案在2007年啟動時，DDD還是一個相當新的理念。您的團隊、客戶對於DDD概念，如領域模型、通用語言、有界上下文，處於什麼經驗水平上？

Bogard：技術負責人（我自己）和架構師有幾年構建DDD系統的經驗。我的第一個DDD專案是在2005年，我還向那個專案的產品團隊介紹了XP和Scrum。對於有界上下文，我們就沒有多少經驗，雖然社群那會更關注結構化模式。

InfoQ：在這個過程中，您認為你們的經驗水平導致了什麼重大的失誤嗎？例如，所遵循的設計和開發實踐導致了不必要的軟體複雜度。

Bogard：不，沒有。設計概念需要經過幾個專案的迭代才會變成今天的樣子。最大的錯誤——沒有有界上下文——那會需要客戶認同構建更小的系統。那沒有發生。此外，我們非常謹慎，只構建我們需要的東西，並且根據我們知道的假設進行設計。由於範圍太大，所以我們知道，如果沒有完成比賽的希望，我們就不可能獲得金牌，因此，我們盡力推遲複雜的需求。

InfoQ：該系統的構建和付款都是在一個機構完成的，但需要滿足其他各種組織的需求。這導致領域模型設計做出了什麼妥協嗎？使用的語言真的是通用的嗎？

Bogard：當然，這導致了設計上的妥協。有時候，我們的設計有點天真，一旦我們瞭解了一個方面的所有領域，我們就會看到，其設計與系統的其他部分基本上是不相容的。因此，我們就得妥協。在語言方面，我們發現，雖然術語是通用的，但背後的意思可能不同。只有把各個領域的專家都聚到一個屋裡來，那才會顯現出來。我們遇到過，每個人都認為他們同意了，但在會議結束時，沒人同意。

InfoQ：在您的第二個專案中，方法上有哪些主要的差別，尤其是從DDD的角度來看？這些差別是如何反映在現實生活中的？

Bogard:：最大的差別是採用了有界上下文。我們在我們的系統和其他系統之間構建了一個反腐層，這樣，當其他機構要和我們的系統連線時，就可以使用他們熟悉的術語和設計，但是我們內部會轉換。例如，執法人員和檢察人員都有“違法（offense）”的概念。在實際的系統裡，我們會分成兩個概念，因此，有兩個名為“違法”的領域物件——一個面向執法人員，一個供我們自己使用。把它們分開，意味著我們可以單獨修改其中一個而不影響另一個。

InfoQ：和嚴格遵循模式的第一個專案不同，您的第二個專案採用了更為務實的做法。對於完成專案滿足客戶需求並保證程式碼高質量、可維護，您有什麼建議嗎？

Bogard：那些專案是馬拉松，而不是衝刺。要採用更偏向產品思維而不是專案思維的方法，設計要長遠考慮，但要圍繞我們已經做了驗證的假設。如果我們有了新的發現，那麼我們要制定計劃把那些變化包含進來，而不是讓我們的設計隨著時間推移慢慢壞掉。

InfoQ：有些讀者希望更多地瞭解您遵循的設計建議，您有什麼要推薦的嗎？

Bogard：SOLID架構：分片而不是分層。

關於受訪者

Jimmy Bogard 是Headspring的首席架構師，《MVC實戰》一書的作者。同時，他還是一名國際演講者和多產的OSS開發人員。他是分散式系統、REST、訊息傳遞、領域驅動設計、CQRS方面的專家。

檢視英文原文：The DDD Do-Over