面試反思與架構演進指南 從「資料庫驅動」到「DDD 模組化單體」：面試反思與架構演進指南 在技術面試中，有一個看似陷阱、實則極具含金量的經典問題： 「如果讓你重新設計以前做過的系統，你最想修改什麼？」 初級工程師往往害怕承認過去程式碼的不足；而資深工程師（Senior Engineer）則懂得將這個問題轉化為展現「痛點感知能力」 、 「領域驅動設計（DDD）」 與 「架構演進思考」的最佳舞台。 本文將拆解如何將過去典型的「資料庫驅動（DB-Driven）」反模式，重新設計為現代化、低耦合的「模組化單體（Modular Monolith）」，並提供一份可以直接應用於面試與實務重構的完整架構指南。 一、 陷阱：DB-Driven 架構的技術債 在專案初期或 MVP（最小可行性產品）階段，以資料庫 Schema 為核心進行開發是非常常見的做法： [使用者請求] ➔ [Controller] ➔ [Service / ORM] ➔ [MySQL / PostgreSQL (強外鍵關聯 & 複雜 JOIN)] 這種架構在業務簡單時開發極快，但隨著業務規模擴張，會迅速帶來三大災難： 資料庫成為全域變數 ：所有業務邏輯都圍繞著 SQL 表格。修改 products 表的一個欄位，可能會意外破壞 orders 或 inventory 的查詢。 強外鍵（Foreign Key）導致併發瓶頸 ：高併發場景下，跨表外鍵會在寫入時觸發共享鎖（Shared Lock），導致連線池爆滿甚至死鎖（Deadlock）。 歷史資料被破壞 ：過度追求資料庫正規化（3NF）。當商品改名或調價時，如果歷史訂單採用 SQL JOIN 查詢，會導致歷史財務報表錯亂。 二、 思維轉變：DDD 與界限上下文（Bounded Context） 要擺脫「牽一髮而動全身」的泥淖，核心在於切斷跨領域的物理耦合，導入 Bounded Context (BC) 概念。 1. 斷開跨 BC 的資料庫外鍵，改用「ID-Only」與「快照（Snapshot）」 在模組化單體中，跨領域之間 不設資料庫外鍵、不用 SQL JOIN ，僅傳遞純 ID 與下單當下的業務快照。 ❌ 反模式：ORM 強關聯與 SQL JOIN G...