在所有的系統開始運行前，我們或多或少都會有一個最主要的商業目的想要去被實現。

就算是最簡單的一頁式官網或是廣告頁，它的存在目的就是為了: 快速讓人取得訊息。

所以在進行我們的系統設計前，我們必須積極的參與每一次的需求確認與會議內容同步，好在一開始就能對接下來我們將要進行設計與開發的系統有個粗略卻清晰的概念。

商業邏輯的本體論：從現象到本質

需求的三個層次

現象層：用戶說出來的話

• "我要一個可以追蹤物流的軟體"
• "我需要即時追蹤，不能有延遲"
• "我要隨時監控家裡的狀況"

本質層：真正的需求動機

• 對時間控制的渴望
• 對風險的焦慮與管控
• 對責任的承擔與分擔

存在層：系統改變的生活狀態

• 從被動等待到主動掌控
• 從不確定性到可預測性
• 從個人責任到集體協作

程式碼作為形上學的具現化

程式碼是一種具象化的工具，它將原本抽象的商業邏輯透過代碼變成具體的規則。就如同我們無法直接描述抽象的「正義」，但可以透過法律條文讓它變成可實踐的行為規則。

這個過程是「哲學上的抽象與還原」：

• 抽象：從用戶的話語中提煉核心意向性
• 建模：用領域概念描述業務本質
• 還原：透過架構服務讓系統真正運作

這也是現代工程師最重要也非常值得去學習的能力- 一種對於卓越的嗅覺，要怎麼將抽象化的概念慢慢抽絲剝繭成為大展鴻圖的織錦。

當然，就我們討論上一定都是美好的。
在工程師之間，演算法與資料型別就像是我們的巴別通天塔，建立起順暢交流無礙的基礎環境。

然而非程式開發者是不懂得這種語言，哪怕是用AI產生出來的需求規格釐清文件，也會在一些背後的權衡上有技術上的未考量之處。

這樣子模糊的空間無疑是讓我們抓狂的，一個模糊的要求不亞於神殿中祭司突然說"神明需要你們獻上勇氣"。
勇氣的類型很多種，一個盛大的角鬥士盛宴、一個凱旋的征服勝利、一個奧林匹亞的桂冠，乃至於承認內心中的想法。那我們該怎麼做，該怎麼知道我們的神明真正需要的是什麼?

所以我們就需要 Domain-Driven Design 的哲學思維脈絡

DDD：領域驅動的認知框架

為什麼需要 Domain 思維？

Eric Evans 在《Domain-Driven Design: Tackling Complexity in the Heart of Software》中強調：工程師不能只追求程式碼的優雅，最重要的是對業務邏輯的深度理解。

但什麼是「業務邏輯」？從現象學角度來看，每個業務都有其意向性（intentionality）- 它指向某個特定的目的和價值實現方式。

投資交易系統的意向性：對時間的極致控制
家庭財務系統的意向性：對集體資源的協調管理
健康監控系統的意向性：對身體狀態的持續認知

Domain Modeling 的哲學基礎

每個領域都有其獨特的存在論結構：

領域存在論
├── 實體 (Entities) - 有身份的核心概念
├── 值對象 (Value Objects) - 描述性屬性
├── 聚合 (Aggregates) - 一致性邊界
└── 領域事件 (Domain Events) - 狀態變化的意義

這不只是技術模式，更是理解業務本質的認知工具。

Event Storming：讓業務現象現形

從事件看見業務的時間性

Event Storming 的核心洞察：業務本質上是時間中的事件序列。

傳統需求分析問「系統要做什麼」，Event Storming的發明者Alberto Brandolini 則指出另一個重要的問題「什麼事情發生了，為什麼重要」。

物件與物件的交互建立在事件的發生，而事件的發生後則造成物件資料的差異。

這是一個非常重要的概念，因為資料(data)的存在原理就是因為資訊(info)的變化，而資訊(info)的變化為何被記錄下來成為資料(data)是因為要實現一個抽象的商業邏輯。

也正因為如此，Alberto Brandolini才會強調每一個事件的關聯性並探討事件與事件應用需求。

實戰框架：現象學式的 Event Storming ( 股票交易情境 )

Step 1: 識別意義事件
不只記錄「訂單已建立」，更要理解「這個事件對用戶意味著什麼」：

• 對控制型用戶：計劃開始執行
• 對社交型用戶：期待即將滿足
• 對安全型用戶：承諾正式生效

Step 2: 探索事件的意向性
每個事件背後的動機是什麼？

• 「價格警告觸發」→ 對損失的焦慮
• 「預算超支告警」→ 對失控的恐懼
• 「設備離線通知」→ 對責任的擔憂

Step 3: 映射到技術實現
根據事件的意向性決定技術策略：

• 焦慮驅動的事件需要低延遲（WebSocket + Lambda@Edge）
• 恐懼驅動的事件需要可靠性（SQS + DLQ + Retry）
• 擔憂驅動的事件需要可觀測性（CloudWatch + SNS）

需求本體論：MBTI 作為分析工具

為什麼選擇 MBTI？

MBTI 不只是心理測驗，而是認知模式的分類系統。它幫助我們理解不同用戶如何感知世界、做出決策、組織生活。
MBTI我認為他是個好用的情境分割工具，最主要的原因是因為他建立在:

• 外向與否 (E/I)
• 感知方式 (S/N)
• 決策傾向 (T/F)
• 工作風格 (J/P)

這四個象限上，而這也是我們在做決定時幾個大方向的脈絡。

我相信一定有其他的性格解析工具與更加專業的行銷學角色設定側寫，但眼下我們先盡可能簡單且全面地來模擬我們在生活中可能會遇到的情境。

四個認知維度的技術對應：

六個典型案例的實戰深度分析

案例 1: 投資交易系統 [I-N-T-J] - 控制型需求

現象層：「我怕速度不夠快會虧錢」
本質層：對時間的極致控制需求
存在層：從市場的被動接受者變為主動的時間管理者

Event Storming 分析：
市場數據更新 → 價格分析觸發 → 交易決策生成 →
訂單提交 → 交易確認 → 持倉更新 → 風險重算

每個事件的延遲都可能觸發焦慮，因此需要：

• 極低延遲：WebSocket + Lambda@Edge + ElastiCache
• 數據一致性：DynamoDB Transactions
• 故障快速恢復：Multi-AZ + Auto Failover

案例 2: 家庭財務系統 [E-N-T-J] - 協調型需求

現象層：「讓家人一起記錄，避免預算失衡」
本質層：集體責任的協調與控制
存在層：從個人財務管理到家庭治理系統

核心事件：「預算邊界被觸及」

• 這個事件對 ENTJ 用戶意味著「控制力受到挑戰」
• 系統必須立即提供「重新獲得控制」的路徑
• 技術實現：SNS 即時通知 + Lambda 自動調整權限

案例 3: 健康監控系統 [I-S-T-J] - 確定性需求

現象層：「想及時了解身體數據是否正確同步」
本質層：對身體狀態的持續確認需求
存在層：從對健康的被動擔心到主動監控

關鍵洞察：用戶最在意的不是數據本身，而是「數據的可靠性」

• 數據完整性比即時性更重要
• 同步狀態的可見性比功能豐富度更重要
• 技術實現：IoT Core + Timestream + CloudWatch Dashboards

案例4: 智慧家居監控系統 [I-S-T-P] - 適應性需求

現象層：「隨時監控智慧裝置，確保老人小孩安全，能接受偶爾延遲」
本質層：責任承擔中的彈性平衡
存在層：從擔心者到守護者的角色轉換

核心矛盾分析：「隨時監控」vs「接受延遲」

• 日常狀態監控可以延遲（成本優化）
• 緊急事件必須即時（責任底線）
• 技術實現：IoT Device Management + Kinesis + Lambda + SNS

案例5: 包裹追蹤系統 [I-S-T-P] - 透明化需求

現象層：「即時追蹤包裹進度，偶爾誤差可接受」
本質層：對不確定性的溫和控制需求
存在層：從被動等待到主動知情

與案例4的對比哲學：
同樣是ISTP，但責任程度不同：

• 案例4：承擔他人安全的重責任
• 案例5：管理個人期待的輕責任

這種差異直接影響系統設計的容錯策略：

• 家居監控需要備援機制
• 包裹追蹤可以優雅降級

Event Storming中的"等待哲學"：
包裹發貨 → 狀態同步 → 位置更新 →
異常檢測 → 預期調整 → 送達確認

核心事件是「預期調整」而非「狀態更新」

• ISTP用戶能理性面對延遲，只要資訊透明
• 「誤差可接受」意味著系統的誠實告知比完美表現更重要

技術實現的誠實性設計：

• API Gateway：整合多方數據源
• DynamoDB：狀態變更的可追溯記錄
• EventBridge：異步更新的優雅處理
• CloudWatch：系統健康的透明化

案例6: 旅遊分享平台 [E-N-F-P] - 創造性需求

現象層：「隨時記錄旅遊靈感，分享路線圖與交通工具」
本質層：創造力表達與社交連結的渴望
存在層：從個人體驗到共享價值的昇華

ENFP認知模式的技術挑戰：

• E(外向)：需要即時分享與互動機制
• N(直覺)：靈感是瞬間的，需要無障礙記錄
• F(感性)：重視情感共鳴而非功能完美
• P(彈性)：內容形式多變，結構需要適應性

創意過程的Event Storming：
靈感觸發 → 內容捕獲 → 情境標記 →
創意加工 → 分享發布 → 社群互動 → 靈感再生

關鍵洞察：創造性系統的設計哲學

• 捕獲優於組織：先記錄，後整理
• 表達優於完美：能發布比功能完整更重要
• 連結優於內容：社交價值高於信息價值

AWS的創意支撐架構：

• S3：多媒體內容的無限儲存
• AppSync：即時協作的社交互動
• Cognito：身份認證的社群基礎
• Location Service：地理標記的情境化
• 離線同步：靈感不因網路而遺失

六個案例的認知模式矩陣

商業邏輯的轉化發 - 現象x本質x存在

通過今天的哲學分析，我們成功將模糊的用戶表達轉化為清晰的功能需求。但這只是第一步。

當我們開始設計具體的 AWS 架構時，會發現還有更深層的問題：

• 「即時」到底意味著多少毫秒的延遲？
• 「隨時監控」需要支撐多大的併發量？
• 「不能失敗」意味著幾個 9 的可用性？
• 「成本可控」的預算上限是什麼？

這些就是非功能需求 - 它們決定了系統的技術規格和 AWS 服務的具體配置。

明天我們將探討「領域邊界與基礎需求確認」，深入討論 API 設計、容量規劃、disaster recovery 策略等技術規格的哲學基礎。

今日的認知框架

• 商業邏輯的本體論：從現象到本質到存在的三層分析
• DDD 的認知價值：領域模型作為業務理解工具
• Event Storming 的時間性：在事件中看見業務的意向性
• MBTI 的技術映射：核心使用者認知模式決定架構選擇

記住：架構師的核心能力不是記住 AWS 服務清單，而是理解「為什麼用戶需要這個系統」。技術只是實現目標的手段，目標背後的人性需求才是設計的哲學基礎。

「每個系統都有其意向性，它指向用戶存在狀態的某種轉化。我們不是在設計功能，而是在設計可能性。」