在領域驅動設計歐洲2016大會上，Paul Rayner在演講中提出將領域驅動設計（DDD）引入敏捷軟件交付過程。他將敏捷視為一種組織工作的方法，而不是一種界定工作方式的規定。他認為敏捷參與者經常不夠重視設計，建議使用DDD概念作為一種克服這些缺點的方式。更進一步，Rayner認為，敏捷與DDD的結合可以加速軟件交付。
在從事顧問工作的過程中，Rayner見過許多踐行敏捷的團隊強調MVP（最小可行產品）的重要性以致損害了設計。他引用了Douglas Martin關于設計必然性的觀點：“好設計的替代品是壞設計，而不是完全無設計。”避免瀑布方法中的“大量提前設計”，只做最低限度的工作，這些團隊最終獲得了壞設計。實際上，敏捷宣言宣稱，“不斷關注優秀的技能和好的設計會增強敏捷能力”。敏捷的目的不只是速度，而是敏捷性。好的設計可以實現敏捷性。這實際上就是設計的目的，Rayner援引Venkat Subramaniam的話對此進行了佐證：“好的設計不是正確地預測了未來的設計，而是讓適應未來的成本不那么高昂的設計。”
他指出，設計基本上是迭代的，這樣一來就很容易包含到敏捷中。設計是一個發現未知并簡潔地表達復雜觀點的過程。由于你永遠無法提前知道所有的一切，所以設計必然會隨著時間變化。花些時間用來發現，并在交付的代碼中表達新知識，這樣會節省后續過程的時間，因為代碼本身變得更加敏捷了。一種方法是“旋渦模式探索過程（whirlpool process of model exploration）”。在這個過程中，你反復使用新場景挑戰已有的領域模型，提出新模型，并編寫代碼實現它。
Rayner還列出了其他一些敏捷團隊使用過的、從DDD的視角來看經常失敗的方法。一個是認為不斷地重構為好的設計已經夠了。這可能會實現清理代碼的效果，但DDD強調引入新概念。這些新概念不是從代碼中出現的，因此無法僅僅通過重構創建出來，而是要在業務建模中形成。它們會增加業務價值，而重構，根據定義，并不改變軟件的功能。
Rayner提到，在Scrum中，一個定義好的“產品經理”角色很容易讓團隊中的其他人將其視為所有業務需求/知識的唯一中轉。DDD倡導，每個人都了解領域。這就是復雜之處，不是在問題的技術層面上。因此，為了實現一個好的設計，提高敏捷性和價值，交付團隊中的每個人都需要了解領域。
查看英文原文：Paul Rayner Says DDD and Agile Can Coexist
京公網安備 11010502049343號