ChatGPT可以幫你寫代碼，但它無法告訴你「這個系統存在的目的是什麼」。這正是哲學思維對架構師而言的核心價值所在。
在我是個工程師之前，我曾經做過救生員（高中時的打工）、游泳教練（是的，短時間的救生員之後我被添加上了一個新的任務）、數據分析師、登山嚮導、私廚、數位行銷策畫，甚至是塔羅師的經歷。
在眾多不同的工作內容中，有一個脈絡被我歸納出來，並且發現其實每一個工作與想要執行的事物都可以按照這個脈絡進行，目的取向。後來在軟體工程的世界裡，我才知道這叫做「領域驅動」。
系統，代表的是一個功能的完整實現，具有其哲學意涵與有機性。
就像生物的生命目的是延續自己一樣，每個系統的誕生都是為了實現某個特定目的：
系統設計其實是一種概念化的仿生學——我們設計它的進食（輸入）、消化（處理）、轉換（計算）與目的實現（輸出）。就像一個人體：
身為軟體工程師，我們必須緊緊依照「目的」來設計系統，否則就會出現災難。
想像可能會出現(根據我的日常經驗中，絕對會出現過)的情境：
這就像一頓精緻料理卻沒有主食，或一個登山嚮導卻沒有正確地圖。錯的不是材料，而是設計者忘記了「目的」。
身為軟體工程師，我們必須緊緊依照目的來設計系統，否則就會出現災難：一個不符合出廠標準的齒輪、無法讓饕客滿足的餐點，錯的不是材料，而是設計者。
很多人習慣用 BDD（Behavior-Driven Development, 行為驅動開發） 來思考系統，跟著用戶的操作軌跡設計功能。
這沒有錯，特別適合產品剛起步時的驗證與快速迭代。
但就像密林是從草原逐漸生長起來的，當系統複雜度增加時，不同的操作情境會成為覆蓋陽光的藤蔓，商業邏輯的維護成本會熵增，最終達到被捨棄或重構的臨界值。
這就是為什麼架構師要掌握 DDD 的高視角。
DDD的價值在於：它讓我們從更高的視角俯瞰整個系統架構。
DDD 的價值不僅僅在於「程式碼的分層」，更在於它讓我們回歸「目的」：
領域模型 是對現實世界規律的抽象。
界限上下文（Bounded Context） 幫助我們劃定「什麼屬於這個子系統，什麼不屬於」。
聚合（Aggregate） 是我們對「事物」的完整定義，而非僅僅一個資料表。
當我們依循每一個「領域」去思考脈絡、設計操作情境、收束狀態變化，我們就能讓第一次踏入系統的開發者快速掌握規律，不會陷入行為特例構築的泥沼。
DDD 的價值不僅僅在於「程式碼的分層」，更在於它讓我們回歸「目的」：
這對AWS架構師來說特別重要，因為雲端服務的選擇太多了，沒有領域邏輯指引，你很容易迷失在服務清單裡。
舉個 AWS 架構的例子：
如果僅用 BDD，你可能會因使用者需要「上傳檔案」而直接放一個 EC2 + FTP。
但若用 DDD，你會問：「在這個領域，檔案的目的與價值是什麼？」
是單純存放？ → S3。
需要版本管理？ → S3 + DynamoDB metadata。
需要事件觸發？ → S3 + EventBridge + Lambda。
需要跨區分發？ → S3 + CloudFront。
DDD 幫助架構師避免只看到「行為」而忽略「目的」。
特別是現在，當算力大爆發讓AI生成代碼的速度遠超人工coding時，Domain知識的深度和對業務邏輯的掌握，成了真正的競爭壁壘。 能否理解業務領域與目的，並轉譯成架構與設計成為了最重要以及最需要的能力。
這就是我想在30天跟大家分享的核心：不只是分享怎麼用AWS工具，而是分享我用領域驅動的思維來設計雲端架構。
AI 可以幫你補齊程式碼的語法細節，但它無法替你回答：
「這個服務應該放在單體架構還是微服務裡？」
「要不要分割資料庫？業務上為什麼需要分割？」
「跨國部署是單純的技術選項，還是業務戰略的需求？」
這些問題背後隱藏的，是 哲學思維：追問「為什麼」，而不僅是「怎麼做」。
很多人以為架構師的工作就是「畫架構圖」或「挑選 AWS 服務」。事實上，這只是冰山一角。
真實世界中的架構師，面臨的是以下困境：
架構師要能在這些拉扯之間找到「目的導向的平衡點」。
古希臘哲學家亞里士多德提出了「目的因（Final Cause）」的概念：一個事物存在的理由，不是因為它是由什麼構成，而是它要達成什麼目的。
一把刀的目的是切割。
一艘船的目的是航行。
一個系統的目的是解決特定的業務問題。
這和我們在軟體架構中的追問高度契合。
當你在設計一個微服務架構時，你可以問自己：
這個服務的目的因是什麼？
如果只是因為**「大家都在用微服務」**，那就是錯誤的理由。
如果它的目的是**「支撐跨國用戶同時使用，並能快速獨立部署」**，那它才有存在的意義。
哲學幫助我們從「工具崇拜」回到「目的導向」。
架構不只是技術，更是團隊的共同語言。
溝通哲學：
架構師必須將抽象的技術概念翻譯成業務能聽懂的語言。
同時也要將業務需求翻譯成工程師能落地的設計。
決策哲學：
很多時候沒有「最佳解」，只有「當下最合適的解」。
例如：RDS vs DynamoDB。選擇 RDS 可能在未來遇到擴展瓶頸，但選擇 DynamoDB 則在一致性上需要更多思考。
架構師要能接受「有限理性」，並持續迭代。
這個系列會一同走過一個完整的系統從無到有的生命週期，每個階段都會深入AWS的具體實踐，同時強調領域思維的重要性：
核心問題：系統的目的是什麼？
核心問題：領域邊界如何劃分？
核心問題：用戶如何與我們的領域互動？
核心問題：領域如何映射到技術架構？
核心問題：如何讓系統自動化地成長？
核心問題：如何驗證系統實現了預期目的？
核心問題：系統在生產環境中是否健康？
核心問題：如何讓系統持續進化？
當 AI 能自動生成系統，架構師是否會被取代？
答案是否定的。
AI 可以自動生成代碼，但它需要「問題定義」。
架構師的價值在於「定義問題」與「界定目的」。
在後人類時代，架構師更像是「數位哲學家」，負責回答：
這個系統是否該存在？(Who am I ?)
它的邊界與責任是什麼？(Where am I from？)
它會對人類社會帶來什麼影響？(Where am I going？)
領域驅動的AWS架構思維：不只分享工具使用心得，更分享用領域視角思考雲端設計。
哲學深度與技術實踐並重：每個技術決策都會探討背後的「為什麼」。
多元背景的獨特視角：結合救生員的風險評估意識、美食愛好者的品質追求、登山領隊的路徑時程規劃思維。
實戰經驗分享：真實項目去業務與脈絡化經驗，包括踩坑教訓和成功實踐。
一套用領域思維駕馭AWS的完整框架、面對AI時代不會被淘汰的核心競爭力、還有從系統目的出發進行架構設計的哲學深度。
更重要的是，我們會開始用架構師的高視角俯瞰系統全貌，而不只是專注於局部的技術實現。
準備好開始這30天的旅程了嗎？接下來我們將從「需求分析與商業邏輯轉換」開始，聊聊AWS架構師如何理解系統存在的真正目的。
「系統的設計，是概念化的仿生學。我們不只是在寫代碼，更是在創造有目的、有生命力的數位生物。」
iThome鐵人賽
看影片追技術