DDD、SDD、TDD:三個維度的邊際效益矩陣
軟體團隊常把 DDD、SDD 與 TDD 當成三選一的方法論,但它們其實分別處理領域語言、介面契約與重構風險。本文用三軸矩陣拆解三者在不同複雜度、協作邊界與變更成本下的邊際效益,提供判斷何時投資建模、規格或測試的實用框架,避免把方法論討論變成宗教戰爭。
軟體團隊常把 DDD、SDD 與 TDD 當成三選一的方法論,但它們其實分別處理領域語言、介面契約與重構風險。本文用三軸矩陣拆解三者在不同複雜度、協作邊界與變更成本下的邊際效益,提供判斷何時投資建模、規格或測試的實用框架,避免把方法論討論變成宗教戰爭。
DDD, SDD, and TDD address different risks: domain language, interface contracts, and change safety. This matrix shows where each method pays off.
PM 丟 Figma,工程師回 API spec。起點選錯,後期重構成本可能翻倍。拆解 Design-First、API-First、Code-First 的取捨,並提供 AI 時代的混合實戰框架。
A PM drops a Figma link, and an engineer replies with an API spec. Pick the wrong starting point, and later refactor costs may double. This post breaks down the tradeoffs among Design-First, API-First, and Code-First, and offers a practical hybrid framework for the AI era.