iT邦幫忙

鐵人檔案

2025 iThome 鐵人賽
回列表
Build on AWS

AWS架構師的自我修養:30天雲端系統思維實戰指南 系列

ChatGPT寫代碼比我還快,Copilot提示比我還準,那身為工程師的我們到底還剩什麼價值?答案是:AI可以幫你寫代碼,但它不會幫你思考「為什麼要這樣寫」。
本系列《AWS架構師的自我修養》正是為此趨勢而生。透過30天的系統性討論,我們將探討如何在AI解放coding後,專注於領域(Domain)驅動的實作方法。內容涵蓋五大核心能力:從業務需求分析的架構師思維養成,到AWS服務選型的系統化決策框架;從DevOps實踐的自動化流程設計,到可觀測性架構的企業級實現;最終整合為完整的雲端解決方案設計能力。
本系列適合3-5年經驗、想要成為真正能夠駕馭AI工具、設計雲端架構的現代工程師。

參賽天數 27 天 | 共 35 篇文章 | 6 人訂閱 訂閱系列文 RSS系列文
DAY 1

Day 1 | 系列開場與導讀:從0開始打造可交付的系統設計-以AWS為例

為什麼一個架構師需要哲學思維? ChatGPT可以幫你寫代碼,但它無法告訴你「這個系統存在的目的是什麼」。這正是哲學思維對架構師而言的核心價值所在。 在我是個工...

2025-09-01 ‧ 由 Otto_auto 分享
DAY 2

Day 2-1 | 需求確認 × 系統設計起點(一):商業邏輯的轉化發

在所有的系統開始運行前,我們或多或少都會有一個最主要的商業目的想要去被實現。 就算是最簡單的一頁式官網或是廣告頁,它的存在目的就是為了: 快速讓人取得訊息。 所...

2025-09-02 ‧ 由 Otto_auto 分享
DAY 3

Day 2-2 | 需求確認 × 系統設計起點(二):領域邊界與基礎需求確認

昨天我們從用戶的話語中萃取出了功能需求的本質,理解了不同認知模式下系統存在的目的。但當我們準備將這些抽象理解轉化為具體的 AWS 架構時,會發現一個關鍵問題:...

2025-09-03 ‧ 由 Otto_auto 分享
DAY 4

Day 3 | 需求萃取方法論-抽象建模(Abstract Modeling)

前三天我們完成了一個重要的認知轉換:從用戶的模糊表達中萃取出功能需求的本質,再從功能需求推導出具體的技術邊界。我們知道了系統要做什麼,也知道了要做到什麼程度。...

2025-09-04 ‧ 由 Otto_auto 分享
DAY 5

Day 4| 用 DDD 建構業務邏輯:從用例到聚合設計

昨天我們完成了抽象建模的四重境界,從概念、行為、資料、架構四個維度理解了系統的本質。但當我們要將這些抽象理解轉化為可執行的業務邏輯時,面臨一個關鍵挑戰: 如何將...

2025-09-05 ‧ 由 Otto_auto 分享
DAY 6

Day 5 | 使用者的系統操作情境 - User Story 與 Scenario Flow

昨天我們完成了領域聚合的設計,建立了業務邏輯的靜態結構。但聚合只是概念框架,真正的價值在於使用者如何與這些業務概念互動。 今天我們要解決一個關鍵問題:如何將抽象...

2025-09-06 ‧ 由 Otto_auto 分享
DAY 7

Day 6 | Trade-off的成本管控藝術:雲端架構的Instance選用

昨天我們建立了完整的User Story框架,將抽象的聚合設計轉化為具體的操作情境。每個Story都包含明確的技術約束:投資交易系統需要<100ms響應、...

2025-09-07 ‧ 由 Otto_auto 分享
DAY 8

Day 7 | 畫出你的第一份系統藍圖:架構選型與設計

經過六天的深度分析,我們已經建立了完整的設計基礎:從哲學思考到領域建模,從用戶需求到服務選型。今天要解決的核心問題是: 如何將所有這些分析整合成一份可執行的系統...

2025-09-08 ‧ 由 Otto_auto 分享
DAY 9

Day 8 | 畫面元件模組設計系統化:設計系統與原子化架構導入

經過前七天從哲學思維到後端架構的完整建構,今天我們要解決一個關鍵問題:如何將後端的聚合邊界和業務邏輯在前端實現系統化的組件設計? 這不只是UI組件的技術問題,更...

2025-09-09 ‧ 由 Otto_auto 分享
DAY 10

Day 9 | 高併發與限流設計:如何避免資源瓶頸

昨天我們建立了三套API架構:投資交易的WebSocket主導、家庭財務的REST簡化、健康監控的混合策略。今天要解決一個更本質的問題:當系統面臨大量併發請求時...

2025-09-10 ‧ 由 Otto_auto 分享