軟體架構（Software Architecture）決定系統如何切分責任、管理資料、連接外部服務，以及部署與運行方式。這些決定會影響後續需求加入的難度，也會改變團隊理解與維護系統所需的時間。
架構討論需要同時考慮需求變化、團隊能力與未來演化方向。框架、資料庫或服務拆分方式，都會帶來落地後的維護責任。當需求仍不穩定，架構就要替尚未確定的部分保留調整空間。
需求會改變系統需要承擔的責任，也會改變各項架構決策的適用條件。當產品仍在探索階段，業務規則、使用流程與服務對象都可能調整。架構若過早固定太多細節，後面就會被迫在模組與資料結構之間繞路。
例如，一套原先只服務單一公司的內部系統，若開始支援多家公司使用，帳號、權限、資料隔離、計費與稽核方式都會改變。這類需求變化會影響資料模型、服務邊界與部署方式，需要回到系統結構重新判斷。
團隊可以先辨識哪些需求相對穩定，哪些內容仍屬於探索中的假設。法規要求、交易一致性與資料保留期限，需要提早納入架構設計。介面流程、功能組合與部分商業規則，可以透過模組化設計保留修改空間。
架構決策紀錄（Architecture Decision Records, ADR）可以保存當時的需求背景、限制條件與採用理由。後續需求發生改變時，團隊能重新檢查原有決策是否仍然成立，再決定要延伸、調整或替換原有方案。
架構方案需要由團隊建置、運行與維護，因此組織現有能力會直接影響方案是否可行。團隊熟悉的技術、部署能力、測試基礎、維運經驗與跨團隊協作方式，都應該納入架構評估。
例如微服務架構（Micro-services Architecture）需要服務治理、自動化部署、監控、追蹤、故障隔離與資料一致性處理。缺少相關能力時，團隊便無法應對服務拆分帶來的大量網路呼叫、部署依賴與故障診斷工作。系統表面上被切成多個服務，日常工作卻可能變成排程協調、環境問題與維運排查。
組織結構也會影響系統邊界，依據康威定律（Conway's Law），系統切分方式應與組織結構相符。當一個模組需要三個團隊共同修改，任何需求都會經過排程、確認與交接。這類邊界即使在程式設計上清楚，交付流程仍會產生等待。
架構設計需要看見實際責任歸屬，讓系統邊界與團隊能承擔的工作範圍維持合理關係。
團隊也可以把能力缺口列入架構工作，例如先建立部署管線、補上關鍵測試、導入可觀測性，或安排小型概念驗證（Proof of Concept, PoC）。這些工作能讓架構方案建立在可執行的驗證上，避免正式導入後才發現實際能力不足。
系統會隨著產品方向、使用規模、法規要求與技術環境改變。架構需要讓部分決定可以延後，也要讓已經做出的決定保有調整餘地。
保留演化空間可以從邊界與契約開始。模組透過清楚介面交換資料，內部實作便能在不影響其他區域的情況下修改。
外部整合若有穩定契約、版本管理與相容性規則，團隊也能分批更新服務，減少單次改動牽動整個系統的風險。
資料設計需要更審慎。程式碼可以透過重新部署替換，資料一旦累積，就需要面對遷移、相容與稽核問題。資料擁有權、生命週期與交換格式若缺少明確規則，後續每次拆分或整合都會增加轉換成本。
演化式架構（Evolutionary Architecture）強調利用測試、架構適應度函數（Architecture Fitness Function）、監控與固定檢查，確認系統仍符合預期方向。
架構適應度函數可以視為架構演進過程中的檢查機制。團隊透過一組可執行、可觀察或可量測的評估方式，確認系統是否仍符合重要的架構特徵，例如效能、可靠性、安全性、延展性與程式碼規範。
這些函數提供多個面向的回饋訊號，幫助團隊判斷目前架構是否偏離預期。當系統經過需求調整、功能擴充或技術重構時，團隊可以依據這些訊號修正方向，讓架構演進保持在可控範圍內。
團隊可以設定依賴規則、效能門檻、安全要求與服務契約，讓架構限制能被自動驗證。這些檢查會在變更進入系統時提醒團隊，哪些邊界需要被守住，哪些風險需要先處理。
架構決策會改變系統未來修改、理解與運行所需的投入。某個方案在開發初期看起來速度很快，需求增加後可能變成跨模組修改。完整分層與服務拆分也會帶來部署、監控與維護工作。
團隊評估架構時，需要把成本放進較長的時間範圍觀察。除了建置功能需要多少時間，也要看需求改變時會碰到哪些區域、新成員要查哪些資料，以及正式運行後需要多少基礎設施與維運能力。
變更成本（Cost of Change）指的是團隊修改需求時，需要投入多少分析、開發、測試、協調與部署工作。架構邊界若貼近變更原因，一項需求可以在有限範圍內完成。責任分散在多個模組時，小修改也會帶動多個相依區域。
例如，折扣規則同時散落在訂單、付款、會員與報表模組中，每次調整活動條件，團隊都要找出所有相關位置，確認資料計算是否一致，並執行較大範圍的回歸測試。規則若集中在清楚的業務邊界內，影響範圍就能被清楚判斷。
變更成本也受到契約穩定度影響。模組透過明確介面交換資料，內部實作便能獨立調整。介面若經常隨內部細節變動，上游與下游都需要配合修改，原本局部的需求就會形成跨團隊工作。
團隊可以從歷史變更觀察架構是否帶來過高成本。例如某類需求是否經常修改相同區域、一次小改動是否需要大量回歸測試，以及跨服務調整是否總是等待其他團隊。這些紀錄能指出哪些邊界需要重新整理。
理解成本（Cost of Understanding）是開發者在修改系統前，需要花多少時間理解業務規則、程式結構、資料流與設計限制。系統可以正常運作，新成員卻可能要讀大量程式碼、詢問熟悉系統的人，才能判斷該從哪裡改。
架構中的抽象層次、命名方式與模組責任，都會影響理解速度。抽象層過多時，開發者需要在介面（Interface）、配接器（Adapter）、服務（Service）與資料模型（Data Model）之間反覆追蹤。抽象不足時，不同責任混在同一區域，閱讀者也很難判斷程式碼為何放在這裡。
理解成本也會受到團隊知識分布影響。某個服務只有一位工程師了解，即使程式結構清楚，其他人接手時仍會缺少設計背景與操作經驗。
架構決策紀錄、系統圖、共同設計與程式碼審查，可以把這些知識留在日常工作裡。
團隊評估架構時，可以請未參與原始設計的人說明某項功能如何運作，觀察他需要查閱哪些資料、詢問哪些人，以及花多少時間找到修改位置。評估這段接手過程會比抽象討論更接近真實狀況。
運行成本（Operational Cost）包含基礎設施費用、部署管理、監控告警、故障處理、安全更新與值班負擔。架構增加新的服務、資料庫、訊息佇列或雲端元件後，團隊也需要承擔對應的管理工作。
將系統拆成大量服務，可以讓部分功能獨立部署，也會增加服務發現、網路延遲、權限設定、分散式追蹤與故障排查工作。團隊若缺少平台架構能力，可能會讓每個服務各自有自己的部署流程、監控規則與維運文件。
運行成本也包含事故發生後的處理難度。跨越多個服務的流程若缺少追蹤資訊，維運人員需要從不同日誌中拼湊事件順序。資料由多個系統共同管理時，恢復與補償流程也需要更完整的設計。
架構方案是否可行，需要回到組織目前能提供的運行能力。團隊可以先估算模組數量、環境成本、部署頻率、告警數量與值班責任，再判斷新增複雜度是否符合產品規模。
可演化的系統邊界，重點在於讓變更能被限制在合理範圍內。當業務規則、資料格式或整合方式改變時，團隊需要知道哪個模組負責處理、哪些區域會受影響，以及哪些契約不能隨意改動。
邊界設計需要同時考慮業務責任、資料擁有權與團隊分工。這些內容若彼此分離，系統容易出現責任交疊、資料重複與跨團隊協調問題。邊界清楚後，內部實作才有機會獨立調整。
模組邊界可以依照單一功能原則（Single Responsibility Principle, SRP）來判斷，即一個模組應該只有一個被改變的原因。當一組規則受到相同業務事件影響，放在同一個模組內，後續修改時就能維持一致。彼此很少一起改變的責任若被放在同一區域，需求調整時就會碰到無關程式碼。
例如，訂單成立、價格計算與付款確認看起來都和交易有關，實際變更原因並不相同。價格計算會隨促銷規則改變，付款確認會受到金流商與對帳流程影響，訂單狀態則和出貨、取消及客服流程有關。團隊若把這些責任集中在大型服務中，每次修改都可能影響整段交易流程。
模組邊界也需要透過依賴方向維持穩定。業務規則應避免直接依賴畫面框架、資料庫細節或外部服務格式。外部技術發生變動時，影響應留在隔離的轉接區域，減少業務邏輯一起重寫的範圍。
團隊可以從過去的修改紀錄檢查邊界。某些檔案若經常在不同需求中一起變動，代表它們可能共享責任。某個模組若每次修改都牽動大量區域，則要重新檢查責任是否過度集中。
資料會長期留在系統中，因此資料邊界需要較早確認。程式模組可以重新切分，資料若已被多個系統共同寫入，後面就會牽涉遷移、相容、權限與歷史紀錄處理。
團隊需要先說清楚每一類資料由誰擁有、誰可以修改，以及其他模組透過什麼方式取得。當多個服務直接寫入同一張資料表，短期整合速度可能較快，後續任何欄位或規則調整都需要同步協調。資料庫會成為共享實作細節，服務之間也容易形成隱性耦合。
資料邊界還包含生命週期與一致性要求。訂單、付款與庫存資料可能需要在不同時間點達成一致，團隊要明確定義哪些狀態可以暫時不同步、哪些錯誤需要補償，以及哪個來源具有最終判定權。
在拆分系統前，先畫出資料流向、寫入責任與查詢依賴，可以提早看見邊界問題。這些資訊也能幫助團隊判斷是否需要事件、API、資料複本或批次同步，以及每種做法會帶來哪些延遲與維護負擔。
系統邊界跨越團隊後，介面與資料格式就會成為協作契約。契約一旦變動，上游與下游團隊都需要判斷影響，因此變更方式、相容規則與通知流程需要事先建立。
API、事件格式與共享資料模型都屬於契約的一部分。契約內容應說明欄位語意、必填條件、錯誤回應、版本方式與棄用期限。文件若缺少業務語意，使用者仍可能誤解資料代表的意思。
契約測試（Contract Testing）可以協助團隊及早發現不相容變更。提供端修改介面時，測試能檢查既有使用方式是否仍可運作。使用端也能用測試表達自己依賴的欄位與行為，避免問題拖到整合階段才出現。
跨團隊契約也需要有明確責任。團隊要知道誰負責批准破壞性變更、誰維護版本資訊，以及異常發生時由誰協調處理。
契約管理若能放進程式碼版本、持續整合與發布流程，各團隊就能在共同規則下調整自己的系統。
AI 能快速產生程式碼、測試與設定檔，也能協助開發者探索不同實作方式。生成速度提高後，更多設計決定會在短時間內進入系統。每一段程式都可能符合眼前需求，組合起來後卻可能讓模組責任、資料擁有權、依賴方向與運行成本變得混亂。
架構判斷負責把局部變更放回整體系統中檢查。團隊需要確認新的實作會放在哪個邊界、依賴哪些元件、改變哪些契約，以及未來由誰維護。
這些判斷需要結合需求背景、系統限制與團隊能力，單次生成結果看不到完整的脈絡。
AI 擅長根據明確指令完成局部工作，例如新增 API、建立資料存取程式、補上驗證邏輯，或將既有程式改寫成另一種結構。這些任務範圍清楚，生成結果也容易透過測試確認。
局部功能快速完成後，團隊容易在缺少整體檢查的情況下繼續擴充。同一項業務規則可能分別出現在前端、後端與批次程式中，新的整合也可能直接依賴其他模組的內部資料結構。結果就是單次變更都能運作，系統的依賴關係卻會越來越難追。
AI 也會沿用提示詞（Prompt）、範例程式與現有結構中的模式（Pattern）。現有設計若包含責任混合、錯誤依賴或不清楚的資料邊界，生成內容就可能延續相同做法。某個臨時解法經過多次生成後，會散佈到更多程式區域。
團隊可以在生成前先標示目標模組、允許依賴與資料來源，生成後再檢查變更是否仍停留在預期邊界內。這類架構檢查能避免局部實作順手跨過邊界。
AI 需要足夠的架構背景，才能產生符合系統方向的內容。提示詞若只有「新增付款功能」，AI 不知道付款狀態由哪個模組管理、交易資料由誰擁有，也不知道系統對一致性、稽核與失敗補償有哪些要求。
架構背景可以包含模組責任、依賴規則、資料擁有權、API 契約、錯誤處理方式與品質要求。這些資訊能縮小 AI 自行補完設計的範圍，讓生成結果較容易接入既有系統。
團隊也可以把架構規則直接放進 AI 會讀取的專案上下文中，例如使用 AGENTS.md、CLAUDE.md，或建立固定的提示詞範本。
內容可以寫明模組依賴方向、禁止跨越的資料邊界、命名規則、外部服務存取方式，以及哪些區域需要人工審查。AI 在執行任務前先讀取這些規則，生成內容才會有明確的限制條件。
例如，團隊明確規定訂單模組不能直接呼叫外部金流服務，需要透過付款介面送出請求，AI 產生的程式就能遵循既有依賴方向。若同時提供失敗重試、冪等性與事件格式規則，生成內容也能更符合運行需求。
這些規則也需要跟著架構調整一起更新。若保留著舊邊界，AI 就會繼續依照過期規則生成程式。團隊應該將這類檔案納入版本控制與程式碼審查，讓架構規則的變更和程式碼一起被追蹤。
團隊也可以導入 AI 輔助的自動化程式碼審查（Automated Code Review）。拉取請求（Pull Request，PR）建立後，透過持續整合管線（Continuous Integration Pipeline, CI Pipeline），讓 AI 讀取變更內容、架構規則與相關程式碼，分析新增依賴、跨模組呼叫、資料存取方式與契約變更，協助找出可能違反既有架構限制的位置。
例如，架構規則若要求展示層不能直接存取資料庫，AI 審查可以檢查此次變更是否新增這類依賴。若某個模組只能透過公開 API 使用另一個模組，AI 也可以找出直接引用內部類別、資料表或私有方法的修改。這些結果會在人工審查前先被標示出來，讓審查者把注意力放在真正需要架構判斷的區域。
AI 審查仍需要搭配可執行檢查。依賴測試、靜態分析、契約測試與架構適應度函數，可以提供可重複執行的驗證結果。AI 則能補充規則解釋、變更影響分析與審查摘要。兩者一起放進開發流程後，這些架構限制會在每次變更中留下檢查點，讓團隊及早發現違規依賴、錯誤呼叫與契約破壞。
架構決策多半包含多個時間尺度。團隊需要處理目前需求，也要考慮未來修改、接手、部署與故障處理所需的成本。
AI 可以列出方案與分析條件，最後的取捨仍需要由理解產品與組織情境的人負責。
同一種技術方案放在不同團隊中，結果可能差異很大。例如微服務能支援獨立部署，也要求團隊具備自動化佈署、可觀測性與分散式系統維運能力。事件驅動架構能降低部分直接依賴，也會增加非同步流程、資料一致性與診斷難度。
人需要判斷這些方案的成本是否符合目前規模與團隊能力，哪些複雜度值得承擔，哪些決定可以延後。這些結論也要留下背景、限制與重新檢查條件，讓後續團隊知道當時為何這樣選。
AI 可以協助整理資料、模擬方案與檢查程式，架構責任仍由團隊承擔。系統未來是否容易修改、事故是否容易控制，以及團隊是否有能力維護，都要回到人的判斷與治理機制。
iThome鐵人賽
看影片追技術