還記得我們在 Day 5 提到的 AI-DLC 嗎？這個概念的核心就是「循環」與「適應」。不同的專案需求、團隊狀態、時程壓力，都需要不同的開發模式。就像打遊戲選角色一樣，沒有最強的角色，只有最適合的選擇。

筆者在實際專案中發現，硬套某個開發模式往往會遇到阻力。比如說，對一個簡單的 CRUD API 硬要套用完整的 DDD，反而會讓開發變得笨重；但如果是複雜的金融交易系統，沒有 DDD 的領域建模，後期維護會是場災難。

四大開發模式的流程

TDD - 測試驅動的嚴謹循環

TDD 的核心是那個經典的「紅綠重構」循環。很多人以為 TDD 就是先寫測試，其實重點在於它的節奏感：

Red → Green → Refactor → Repeat

這個循環在 AI-DLC 中特別有效，因為 AI 可以：

• 在 Red Phase 幫你生成測試案例
• 在 Green Phase 提供最簡實作
• 在 Refactor Phase 建議優化方向

實際的環節順序是：

1. Story 分析與拆解
2. 寫失敗的測試（定義預期行為）
3. 寫最少的程式碼通過測試
4. 重構但保持測試綠燈
5. 持續整合與部署

BDD - 行為驅動的協作橋樑

BDD 其實是 TDD 的延伸，但它把焦點從「測試」轉向「行為」。我特別喜歡用 BDD 來處理跨團隊協作的專案，因為 Gherkin 語法讓非技術人員也能參與：

Scenario → Step Definitions → Implementation → Validation

在 AI-DLC 循環中，BDD 的優勢是：

• AI 可以將使用者故事轉換成 Gherkin 場景
• 自動生成 Step Definitions 的框架
• 確保實作符合業務需求

環節編排重點：

1. 與利害關係人一起定義 Feature
2. 撰寫 Given-When-Then 場景
3. 實作步驟定義（這裡可以內嵌 TDD）
4. 執行驗收測試
5. 獲得利害關係人確認

DDD - 領域驅動的架構思維

DDD 是我認為最適合複雜業務邏輯的方法。它不只是個開發模式，更是一種思維方式：

Domain Modeling → Bounded Context → Aggregates → Implementation

在 AI-DLC 中，DDD 的價值在於：

• AI 協助識別領域概念和邊界
• 自動產生領域模型的程式碼框架
• 維持 Ubiquitous Language 的一致性

關鍵環節順序：

1. 領域專家訪談與知識萃取
2. 建立統一語言（Ubiquitous Language）
3. 劃分邊界上下文（Bounded Context）
4. 設計聚合根與實體
5. 實作領域層、應用層、基礎設施層
6. 整合測試與部署

SDD - 規格驅動的明確路徑

SDD 適合規格已經很明確的專案：

Specification → Pan(Story+Acceptance Criteria) → Tasks(Implementation)

AI-DLC 在 SDD 中的角色：

• 將規格文件解析成可執行的需求
• 自動產生測試案例覆蓋所有規格點
• 確保實作完整符合規格要求

AI-DLC 的選擇機制

除了我們自行判斷也可以利用AI，AI 不只是工具，它可以根據專案特徵，推薦最適合的開發模式組合。

情境識別與模式匹配

當你啟動一個新 Sprint，可以讓 AI 分析：

1. 專案複雜度評估
   • 簡單 CRUD → 純 TDD
   • 使用者互動多 → BDD 優先
   • 業務邏輯複雜 → DDD 主導
   • 規格明確詳細 → SDD 路線
2. 團隊組成分析
   • 全技術團隊 → TDD/DDD
   • 有 PM/BA 參與 → BDD
   • 有領域專家 → DDD
   • 有詳細規格書 → SDD
3. 時程壓力判斷
   • 時間充裕 → 完整 DDD + TDD
   • 適中時程 → BDD + 部分 TDD
   • 趕時程 → 精簡 TDD + 快速迭代

混合模式的藝術

實務上，純粹使用單一模式是很少見的。AI-DLC 的強大之處在於它能夠混搭不同模式：

案例一：電商結帳系統

DDD（領域建模） → BDD（使用者流程） → TDD（核心邏輯） → SDD（支付規格）

AI 會建議：

• 先用 DDD 釐清訂單、支付、庫存等領域
• 用 BDD 定義結帳流程的使用者行為
• 核心計算邏輯用 TDD 確保正確性
• 串接金流時遵循 SDD 的規格要求

案例二：內部管理後台

BDD（功能需求） → TDD（實作） → 快速迭代

因為是內部系統，不需要複雜的領域建模，直接從使用者需求出發，快速迭代。

環節間的協作優化

不同模式的環節如何無縫銜接？這是 AI-DLC 要解決的關鍵問題。

資訊流轉的自動化

1. DDD → BDD 的轉換
   • 領域模型自動產生 BDD 場景框架
   • Ubiquitous Language 直接用於 Gherkin
2. BDD → TDD 的細化
   • 每個 Step Definition 展開成 TDD 循環
   • Scenario 產生對應的測試案例
3. TDD → CI/CD 的串接
   • 測試自動觸發部署流程
   • 測試覆蓋率作為品質門檻

反饋循環的建立

AI-DLC 不是單向的，它強調反饋與學習：

• 執行結果回饋到規劃：測試失敗率高的區域，下個 Sprint 優先重構
• 使用者回饋調整模式：如果 BDD 的驗收測試常失敗，可能需要加強 DDD 的領域理解
• 效能數據優化流程：如果某個模式導致開發速度慢，AI 會建議簡化或替換

結論：

把 AI 想像成一個經驗豐富的開發教練，它不會強迫你用某種方式，而是根據當下情況給出最適合的建議。

最近筆者在一個專案中，原本打算用純 TDD 開發，但 AI 分析需求後建議：「這個專案有複雜的會員等級計算，建議先用 DDD 建立領域模型。」後來就嘗試先釐清領域概念後，後續的 TDD 實作順暢很多。

另一個案例是快速原型開發，AI 建議：「時程只有兩週，建議 BDD 定義核心流程，配合最小 TDD 確保關鍵功能正確。」這個建議幫我們在時限內交付了可用的 MVP。