DDD彌補了瀑布和敏捷兩個方法的不足之處！ - 47 North Labs

敏捷的方式
現在，每個軟體開發人員都知道敏捷宣言中提供的敏捷基礎知識，宣言中這些想法可能更抽象，但從現實生活經驗看，我們可以定義十二個原則：

1. 透過早期和持續交付有價值的軟體實現客戶滿意度
2. 歡迎不斷變化的需求，甚至是開發後期
3. 經常提供可執行的軟體（是數週時間而不是數月）
4. 業務專家和開發人員之間的密切，日常合作
5. 專案是圍繞有動力的個人建立的，他們應該受到信任
6. 面對面交談是最好的溝通方式（共址）
7. 可執行的軟體是前進的主要衡量標準
8. 可持續發展，能夠保持穩定的步伐
9. 不斷關注技術卓越和良好的設計
10. 簡單性 - 最大化未完成工作量的藝術 - 至關重要
11. 最好的架構，要求和設計來自自組織團隊
12. 通常，團隊會反思如何提高效率並相應調整

瀑布的方式
瀑布的基本模型流程包含以下幾個階段：

1. 軟體要求
2. 分析
3. 系統設計
4. 編碼和實施
5. 測試和驗證
6. 操作和維護

正確實施敏捷的方法
比較這兩種方式，我們可以發現使用敏捷而不是瀑布會更好更可靠。我們不必等待很長一段時間，才能驗證我們做的是正確的，透過每次迭代都讓客戶逐步接受專案。

但是問題來了：由於不喜歡花時間分析和定義整個資料域，提前滿足所有需求，以根據專案的實際需求建立整個架構，因為這將耗費他們的時間和金錢。所有需求故事都只在專案開始後定義。將它們分成小的需求，這可以在一個衝刺期間完成，沒有無用的工作和努力。

將根據每個新要求，每個新功能或某些錯誤來定義和建立資料模型。一開始，資料模型將很好地執行服務，需求可以快速完成，因為不存在建立新實體並將其引用到現有實體的問題。而我們實現DDD時，首先是定義資料模型然後實現程式碼。

經過一段時間以後，透過沖刺建立了一些資料模型，這時需要更改模型的新需求來了，我們將面臨越來越多的困難，需要使現有的資料模型適應新的需求。在一瞬間，我們將不得不在模型中做出更大的改變。這樣做的主要原因是，當我們實施這些需求時，我們只關注我們在上一個故障單、故事等處理過程中對sprint的需求，而我們並不知道模型對特徵需求的需求。

兩個解決方案：

• 繼續嘗試研究我們現在製作的模型。這將使實施我們的新變更更加困難，並且更加耗時。
• 或者在某一時刻停止使用新功能並花時間在資料模型的大型重構上。這需要很長時間才能在專案中使用新功能進行任何高效工作，只需重構。