對於許多剛進入開發階段的工程師來說，我們習慣於接收「需求清單」，例如：我們需要一個微服務架構、我們需要導入 AI 功能、或者系統必須要很快。然而，在資深架構師 Sonya Natanzon 的觀點中，這種以「解決方案」為導向的需求描述，往往是導致專案失敗或設計偏差的根源。
真正的架構分析，應該是將焦點從「如何實現」移回「為什麼要做」，並在業務目標與技術限制之間建立一座橋樑。
優先考慮業務價值而非技術堆疊
工程師很容易陷入技術迷思，認為選擇了最新的框架或最強的資料庫就是成功的關鍵。但事實上，技術只是達成目的的手段。如果一個系統能讓使用者滿意地完成任務，即便後端邏輯簡單得像「倉鼠轉輪」，它依然是一個成功的產品。
架構師最重要的職能之一，就是理解業務運作模式：公司如何賺錢？使用者為何流失？業務目標是什麼？因為業務端通常不關心軟體如何構建，但技術端必須深刻理解業務，才能將技術決策導向正確的商業結果。
從解決方案回溯到問題陳述
在需求分析中，最危險的句子是以「我們需要... (We need...)」開頭的陳述。這類句子通常是偽裝成需求的「解決方案」。例如，「我們需要微服務」是一個解決方案，而不是一個問題。
一個有效的問題陳述 (Problem Statement) 應該描述兩種狀態： 目前正在發生，但我們不希望看到的壞結果。 我們希望達成，但目前尚未實現的好結果。
當面對「我們需要 X 功能」的需求時，工程師應嘗試詢問：「你試圖達成的有用結果 (Useful Outcome) 是什麼？」透過不斷剝洋蔥式的追問，將解決方案回溯到問題本身，才能為架構設計留出思考空間，避免被過早鎖定在某個可能並非最佳的方案中。
利用限制來簡化設計
許多人認為限制 (Constraints) 是阻礙，但對架構師而言，限制反而是最好的導航工具。在一個完全沒有限制的環境中，選項過多會導致分析癱瘓 (Analysis Paralysis)。
無論是法規要求（例如某些演算法必須絕對隔離）還是資源限制，這些條件能迅速縮小可行方案的範圍，讓設計路徑變得清晰。將限制視為需求的一部分，能幫助團隊更快地達成共識並做出決策。
實踐領域驅動設計的技巧
為了讓技術人員與業務人員在同一頻率上，Sonya 建議引入領域驅動設計 (Domain-Driven Design, DDD) 的核心概念，但不需要刻意向團隊推銷複雜的方法論。
通用語言 (Ubiquitous Language) 這是指一套由技術與業務雙方共同認可的詞彙表。建議直接建立一個簡單的「術語表 (Glossary)」，定義每個詞彙在系統中的具體含義，避免因語言歧義導致的開發錯誤。
隱形實作 (Implicit Implementation) 不必強迫團隊閱讀厚重的 DDD 教科書，而是直接在工作坊中運用其技巧。例如，直接進行事件風暴 (Event Storming，一種透過貼紙在牆上梳理業務流程的協作方式)，讓參與者在不知不覺中完成領域建模，從而降低對新方法論的抵觸感。
AI 時代下的工程直覺與人才培養
隨著 AI 代理 (Agentic AI) 能自動生成大量程式碼，初級工程師面臨著「技能退化」的風險。如果 AI 處理了所有簡單的編碼工作，新人將失去在實作中培養「系統直覺」的機會。
這種直覺是指理解抽象層在何處會失效。例如，當 AI 建議增加 API 訂閱來解決限流問題時，具備直覺的工程師會發現將數據載入記憶體批次處理才是根本解法。
因此，未來工程師的核心能力將從「寫程式」轉向「審閱與解釋程式」。能夠解釋 AI 為何這樣寫、在何處可能出錯，並能定義清晰的邊界與模組化方向，將成為新時代工程師的競爭力。
來源：infoq.com - Requirements Analysis for Architects: A Conversation with Sonya Natanzon
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。