很多人以為，做一套系統就是把畫面和功能寫出來。
登入可以用、訂單送得出去、後台看得到資料，好像就差不多完成了。
但如果你真的準備讓客戶使用，事情其實沒有這麼簡單。
一套系統就像一間房子。
功能是你看得到的家具，真正決定住起來舒不舒服的，卻是水電、管線、隔間和收納。
這些東西平常不明顯，但只要沒有設計好，東西越放越多，最後就會連走路的空間都沒有。
後端系統也是一樣。
第一層：系統要放在哪裡，出了問題怎麼辦？
開始寫程式之前，首先要想的是整套系統要怎麼運作。
例如：
網站突然有很多人使用，撐不撐得住？
其中一台主機故障，服務會不會直接消失？
資料庫壞掉，資料能不能救回來？
圖片、影片和會員資料，應該放在同一個地方嗎？
系統更新失敗，能不能快速換回上一個版本？
這一層通常稱為 System Design，也就是整體的雲端與系統架構。
它很像在規劃一棟建築。
電從哪裡來、水管怎麼走、哪裡需要逃生出口，都不是等房子蓋完才開始想。
小型產品不需要一開始就蓋成摩天大樓。
但至少要知道，哪些地方未來可能會擴充，哪些風險現在就要先處理。
第二層：程式裡的東西，要放在哪一個房間？
決定整套系統怎麼運作之後，接下來才是程式本身的架構。
會員、訂單、付款、通知、權限，應該怎麼分開？
哪些功能可以互相使用？
哪些資料不能隨便被其他地方修改？
這就像家裡的收納。
衣服應該放衣櫃，餐具應該放廚房，重要文件要有固定的位置。
如果所有東西都先隨手塞進同一個房間，剛開始確實很快。
但東西越來越多之後，你會開始找不到東西，也不敢隨便移動，因為不知道底下還壓著什麼。
很多系統後來改不動，就是因為會員、付款、訂單和通知全部纏在一起。
只是調整一個付款流程，卻連會員權限和訂單狀態一起壞掉。
好的程式架構，不是為了看起來比較專業。
而是讓每個部分都有清楚的位置，未來要修改時，知道應該從哪裡開始。
第三層：每一個抽屜裡，要怎麼擺才不會亂？
就算房間分好了，抽屜裡還是可能一團亂。
這時才會進到更細的設計。
例如一筆訂單，什麼時候可以付款？
付款完成後，還能不能修改內容？
取消訂單時，庫存、退款和通知應該怎麼處理？
同一個付款結果送來兩次，會不會重複入帳？
這些細節會透過領域模型、狀態設計和各種設計模式，被放進程式裡。
在 DDD 裡，這一層通常叫做戰術設計。
名字聽起來很複雜，但它做的事情其實很直接：
把重要的商業規則放在固定的位置，讓它不會散落在每一個頁面和 API 裡。
如此一來，之後不管是工程師還是 AI 修改程式，都比較不容易繞過原本的規則。
架構不是把系統做得很複雜
很多人聽到架構，會以為就是使用很多服務、很多框架，再畫一張很厲害的圖。
其實剛好相反。
好的架構，是用適合現在規模的方式，把東西放在正確的位置。
簡單的產品，就用簡單的方法。
但付款、權限、資料安全這些不能出錯的地方，還是要有清楚的規則。
容易改變的功能，要保留調整空間。
暫時用不到的複雜設計，也不需要提前塞進來。
真正困難的不是學會某一套框架。
而是知道什麼時候該用、什麼時候不該用，以及不同設計之間會帶來什麼影響。
AI 可以幫忙施工，但還是需要有人看完整張圖
現在 AI 很會寫程式。
你可以叫它新增 API、串接資料庫、建立後台，速度可能比過去快上好幾倍。
但一套強健的後端系統，背後需要的不只是寫程式的能力。
還要理解雲端架構、資料庫、網路、安全性、程式架構、商業邏輯、測試，以及系統出問題後該怎麼處理。
AI 可以幫忙把磚牆砌得更快。
但房子要蓋在哪裡、房間怎麼分、水電怎麼走，還是需要有人先把整張圖想清楚。
我在設計系統時，會從整體的雲端架構開始，再往下整理程式的責任與邊界，最後把重要的商業規則收進清楚的領域模型裡。
不是為了把系統做得更華麗。
而是讓它今天能上線，明天還改得動，使用者變多之後，也不用整套打掉重來。
