# DDD Applied - Introducing TDD while breaking down legacy monolith

解析極限編程 XP

Code Review > pair programing
測試 > 單元測試，用戶功能測試，先寫測試
架構設計 > 持續重構
簡化設計 > 追求最簡單的實作
集成測試 > 持續集成

增量變化 Incremental changes
假設的簡單性 assumed simplicity
快速反饋快速覆盤 Rapid feedback
擁抱變化 Embracing change
有品質的實作 Quality work

## 為什麼用 TDD?

* 驗證代碼是否正常工作
* 防止未來的功能倒退
* 記錄程式碼的行為
* 提供設計指導
* 支持重構

持久的高速開發
↓
簡潔代碼
↓
重構
↓
信心
↓
測試

## TDD 三部曲

* 編寫測試案例
* 運行測試 > 紅
* 編寫最簡單程式碼去通過測試
* 運行測試 > 綠
* 重構改進簡化

## 黑盒測試

* 從用戶或外部服務的角度進行功能測試
* 測試不了解內部代碼
* 系統的輸入和輸出測試
* 極少的模擬組建與依賴
* 端到端測試 End-to-End 通常是黑盒測試

## 實例方案

* 分析現有單體系統
* 識別潛在服務
* 尋找第一個開發的服務
* 獨立的、高業務價值
* 開始用 TDD 開發第一個服務
* 部署到 pre prod、prod
* 復盤和擴展

## 契約測試
> 關注不同組建之間的接口和交互
> 適用於微服務架構

* 生產者與消費者
* 生產者是提供服務或數據的組件，消費者是一來這些服務或數據的組件
* 測試用例會驗證生產者是否按照契約生成正確的數據，以及消費者是否正確的使用這些數據

## 為什麼要盡快部署到 production

* prod 是最終的驗證
* 只有 production 實戰的無缺陷才真正提供業務價值
* pre-prod 與 prod 環境必須幾乎相同

## 暗部署 Dark Deploy

* 並行部署
* 新代碼或功能會並行部署現有的生產版本旁邊
* 對最終用戶隱藏的新代碼部署
* 用戶會繼續使用當前生產版本
* 隔離與當前的生產版本
* 主要用於測試和驗證

## Strangler Fig Pattern
> [Microsoft 提供的說明](https://learn.microsoft.com/zh-tw/azure/architecture/patterns/strangler-fig)