面試反思與架構演進指南 從「資料庫驅動」到「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...
職涯的先後手：你是「因工作而學習」，還是「因學習而找到工作」？ 職涯的先後手：你是「因工作而學習」，還是「因學習而找到工作」？ 在職場的馬拉松裡，我們無時無刻不在學習。但你是否思考過，推動你拿起書本或打開文檔的動力是什麼？ 學習與工作之間存在著一種有趣的「因果糾纏」。有人是為了完成手頭的任務而不得不學，有人則是為了跨入理想的門檻而刻意修煉。這兩者路徑不同，收穫也大不相同。今天我們就來拆解這兩種學習型態的本質區別。 一、 因工作而學習：實戰驅動的「以戰養戰」 這種模式通常發生在我們已經「在線」的狀態。可能是接手了一個不熟悉的專案，或是遇到了一個令人頭痛的效能瓶頸。 1. 核心特質：極致的目標導向 這類學習的目標非常明確： 解決眼前的問題 。你不會從第一章慢慢讀到第十章，而是直接跳到技術文檔的 Troubleshooting 或 API Reference 。 2. 優勢：學習留存率最高 因為你有真實的場景可以立刻實踐。當你為了排查「為什麼 Docker 環境在雲端變慢」而翻遍底層架構時，那些知識會伴隨著解決問題後的快感，深深烙印在腦海中。 3. 挑戰：知識碎片化 這種學習方式像是在「補洞」，哪裡漏了補哪裡。雖然解決問題的速度快，但容易缺乏整體的系統感，形成「知其然，而不知其所以然」的技術斷層。 二、 因學習而找到工作：投資未來的「門票思維」 這多半出現在職涯的轉折點，例如新鮮人求職，或者是資深工程師計畫跨領域轉職。 1. 核心特質：系統性的打底 為了說服雇主，你需要展現完整的技能樹。因此，學習路徑通常是從基礎理論開始，一步步構建完整的知識體系。 2. 優勢：基礎紮實，應變力強 因為你經歷過系統性的薰陶，當新技術出現時，你更能看透其背後的邏輯（例如從底層原理理解新框架的演進），這讓你在職涯長跑中更有後勁。 3. 挑戰：學非所用的焦慮 最大的挫折感往往來自於「我學了這麼多，真的用得到嗎？」。如果缺乏實作練習，這種學習很容易變成「紙上談兵」，在面對真實世界的複雜問題時顯得力不從心。 三、 兩者的本質區別 維度 因為工作而學習 (Necessity) 因為學習而找到工作 (Preparation) 觸發點 被動問題觸發 主動目標驅動 路徑 由果溯因（從問...