昨天我們探討了快取的三重存在論，今天我們深入到數據的最終歸宿：持久化存儲層。

如果說快取是系統的短期記憶，那麼資料庫就是系統的長期記憶與知識庫。當快取失效、系統重啟、災難恢復時，資料庫承載著系統重新構建世界觀的責任。

但更重要的是：**資料庫設計直接決定了快取策略的有效性。**錯誤的資料庫模式會讓再完美的快取設計都變成徒勞。

資料庫設計的本體論：從存在到結構

在開始資料庫的設計前，我們可能會需要先釐清一個問題

什麼是資料?

資料的本質: 行為影響乃是被記錄的具體

學生在課堂時全神貫注的追隨老師與教授的講解，將知識的個人理解重點記錄在某個載體上；醫生一步步診斷病患自述後根據自己的專業評估逐步記錄病人感覺自述與診斷推估記錄；華爾街股票交易市場不斷記錄買入賣出的價格，這些記錄並再由其他專業經理人整理並記錄成圖表、曲線或是專業分析報告。

注意到規律了嗎? 不論在哪一個載體上，舉凡課堂筆記、醫療診間病例或是股票交易價格變化，其本質上都是遵循著一個規律

行為 => 影響(被記錄) = 被記錄的資料

所有的資料背後都代表著某一個 行為 執行後，所造成的影響。

這個影響可以是根據某個抽象化概念的具體描述，如同語言學對於文法的解析辯證或數學中的對於公式的推導。抑或是狀態經歷過某個 行為 後，產生的新的、被記錄下來的影響具體，就如同我們透過閱讀他人的著作，來了解作者眼中的世界一樣。

那為什麼我們會有 行為 ? 我們做出 行為的依據是什麼?

需求( require )

在我們執行某一個行為前，它必定會被某一個原始或深思熟慮的需求所驅動。渴了我們下意識會想找水喝、遇到危險時會下意識逃跑或戰鬥。同時，當我們感知到我們渴了的時候，也有可能考慮到我們正身處在圖書館，所以會忍住喝水的行為直到可以解渴的情境中。

所以對於資料的產生流程我們可以再度調整成

需求( require ) => 行為(conduct) => 影響(effect)

而這，也是 Domain-Driven 最重要的概念。

我們所有系統設計都有其來源，身為一個系統架構師，我們必須在基於理解需求、了解需求最終解構需求。

所以對於資料庫設計我們也需要分析資料產生的源頭、理解它的誕生原因，然後進行設計。

一個專業的電影製作人員正在創作中的原始檔的儲存方式與同步方式，與在 NetFlix 上發行的電影儲存方式與同步方式，其儲存與使用情境需求是非常之不一樣的。

視角的轉換：從單一事實到多重詮釋

我們剛才建立了 需求( require ) => 行為(conduct) => 影響(effect) 這個核心流程。我們延續一個更深層的問題：誰在記錄？什麼背景情境的記錄？

同一個「影響」，在不同的「觀察者」眼中，會被記錄成截然不同的「資料」。

想像一筆網路書店的交易完成（影響）：

• 對財務部門而言：這是一個會計分錄。他們的需求是「對帳與報稅」，記錄的資料是「訂單金額、稅金、支付方式、時間戳」。
• 對倉儲部門而言：這是一次庫存變動。他們的需求是「管理庫存」，記錄的資料是「商品 SKU、出庫數量、庫存剩餘」。
• 對行銷部門而言：這是一個用戶行為。他們的需求是「分析偏好以利推薦」，記錄的資料是「用戶 ID、購買商品類別、購買關聯性」。

事實（Fact）只有一個：一筆交易發生了。
資料（Data）卻有多個版本：每個部門根據自身的「需求」，從這個「影響」中提取、轉化並記錄了對自己有意義的片段。

這就是系統設計中「界定上下文（Bounded Context）」概念的體現。每個上下文（部門）都有一套自己的語言模型和資料模型，它們都服務於該上下文的特定需求。

因此，我們的資料產生流程可以進一步精煉為：

在「特定上下文」中 =>
  「特定需求」驅動 =>
    「特定行為」產生 =>
      「單一影響」被 =>
        「多重視角」詮釋為 =>
          「多種被記錄的資料」

這個認知直接導向了現代資料庫架構的核心策略，例如：

1. 微服務（Microservices）：每個服務（上下文）擁有自己的資料庫，因為它們對資料的「詮釋」和「需求」不同。強行統一資料庫只會導致模型混亂和權責不清。
2. CQRS (命令查詢責任分離)：將「記錄行為」（命令端）和「查詢詮釋」（查詢端）的資料庫分開。寫入操作優化於記錄事實，讀取操作優化於特定視角的快速查詢。
3. 事件溯源（Event Sourcing）：不直接儲存「狀態」，而是儲存一系列不可變的「影響」（事件）。系統的任何「當前狀態」都只是對歷史事件的一種「詮釋」或「投影」。

所以，當我們設計 Schema 時，不應再問「這個東西有哪些屬性？」，而應該問：

• 這個資料是為了滿足哪個上下文的什麼需求？ (定位 Bounded Context)
• 是哪個行為產生了這個資料？ (追溯 Event/Command)
• 未來會有多少種不同的視角來查詢和詮釋這個資料？ (規劃 Query Models / Read Models)

理解了資料是「被詮釋的影響」，我們才能擺脫單一、僵化的資料庫設計思維，進而擁抱一個更能適應複雜業務變化的、彈性的、多維度的資料架構。