資料驅動設計：將遊戲開發的經驗用於日常軟體

現代軟體常常需要快速適應變化——無論是處理新的資料集、根據使用者偏好進行調整，還是在不停機的情況下安全地部署新功能。為了獲得這種靈活性，軟體工程師越來越多地採用一種稱為資料驅動設計（Data-Driven Design，DDD）的方法論。

資料驅動設計最初因遊戲開發而流行，在 20 世紀 90 年代大型工作室面臨一個棘手問題時嶄露頭角：他們需要對複雜的互動式內容進行快速迭代。遊戲開發者意識到，每當設計師想要微調玩法機制、調整角色行為或修改遊戲內對話時，就重新構建並重新部署整個遊戲，既昂貴又緩慢。

Jason Gregory 頗具影響力的著作 Game Engine Architecture（《遊戲引擎架構》）著重介紹了 AAA 遊戲如何通過將遊戲邏輯外接到結構化的資料檔案中來有效應對這一挑戰。開發者不再把行為直接嵌入 C++ 程式碼，而是從易於編輯的檔案（如 YAML、JSON 或自訂格式）中載入 AI 規則、遊戲關卡、物品描述和劇情對話等資料。這極大地加快了迭代速度，使非程式設計師——美術、設計師和編劇——能夠直接試驗和打磨體驗，而無需重新編譯程式碼或重新部署。

儘管資料驅動設計起源於遊戲開發，但它已在眾多軟體領域證明了自身的價值，涵蓋 Web 開發、資料分析、DevOps 自動化，以及無程式碼和低程式碼平臺。其基本原則始終如一：將通用引擎與領域特定資料分離。

資料驅動設計的核心思想

在深入探討之前，我們先給出一個清晰的工作定義，以說明資料驅動設計為何對當今的開發者和系統管理員具有現實意義：

資料驅動設計是指軟體的行為由外部資料而不是硬編碼邏輯來控制。程式碼提供處理這些資料的通用機制，而“做什麼”或“如何表現”的具體內容則存放在資料檔案（如 YAML、JSON 或資料庫）中，這些資料檔案可以獨立於原始碼本身進行修改。

為進一步說明，下面做一個簡單的對比：

模式	由什麼驅動行為？	實際示例
硬編碼	嵌入在程式碼中的條件語句	if user.is_premium: enable_feature()
配置驅動	配置檔案中的簡單標誌或設定	config.ini 中的 max_connections = 10
資料驅動	在結構化資料（YAML、JSON、SQLite）中定義完整的行為	用 YAML 定義工作流，或用 SQLite 儲存業務規則

下面列出一些常見的誤解和反模式，以幫助釐清概念：

• “這不過是個配置檔案。” ——如果刪除這個檔案會導致程式崩潰，那它就不只是配置；它是定義執行時行為的內容。
• “DDD = 無程式碼。” ——錯：目標是讓引擎保持通用和精簡，但領域邏輯仍然必須存在於某處（通常是由引擎解釋執行的領域特定語言）。
• 過早引入複雜性 ——如果幾份 YAML 文件加一個小型直譯器類就能搞定，就不要發明自訂 DSL。
• 盲目除錯 ——始終記錄“是哪一行資料觸發了這個動作？”，以便快速追蹤缺陷。

最佳實踐與常見陷阱

採用資料驅動設計時，請牢記以下幾點：

實踐	建議
模式校驗	始終強制使用模式（例如 JSON Schema 或 SQLite 遷移）以防止錯誤
熱過載	將解析與資料啟用步驟明確分開
安全考慮	絕不要預設信任外部資料；使用前務必進行校驗或清理
效能優化	在適當的地方快取已載入的資料，避免重複解析

高層架構概覽

典型的資料驅動設計架構會明確劃分以下幾層：

1. 編寫層

   • 人類可讀的格式，如 YAML 或 JSON。
   • 可由使用者直接編輯，也可通過自動化流程編輯。

2. 校驗與構建層

   • 確保資料一致性的模式定義或遷移。

3. 執行時載入器與熱過載

   • 在執行時讀取並校驗資料。
   • 支援熱過載，以便快速迭代。

4. 通用執行時系統

   • 完全依據載入的資料執行邏輯。

這樣就形成了一條穩健的管線：僅修改資料就能觸發不同的應用程式行為。

Data Files (YAML/SQLite)
    │ load & validate
    ▼
Generic Runtime Engine
    │ executes behaviors based on data
    ▼
Dynamic Behavior in Application

選擇資料容器

下面是根據需求選擇資料格式的簡要指南：

格式	優勢	典型用例
YAML/JSON/TOML	人類可讀，便於版本控制	中小複雜度的工作流、配置
SQLite	關係查詢、一致性、單檔案	複雜規則集、關係型資料、分析
二進位制格式	對效能要求極高的載入	嵌入式系統、高效能場景

通常你會從 YAML 或 JSON 起步，隨著複雜度增長再升級到 SQLite。

實踐示例：使用 Divooka 構建資料驅動的工作流

Divooka 是一種視覺化程式語言，它通過可組合的資料流節點天然體現了資料驅動設計的原則。我們用一個簡單的示例來清楚地說明這一點：

場景：

一位資料分析師想要構建一個自動化工作流，用來：

• 載入一個包含客戶訂單的 CSV 檔案。
• 篩選出超過某個閾值的訂單。
• 通過 Web API 傳送彙總結果。

在 Divooka 中，這個流程可以精簡如下：

1. 使用 Path 和檔案節點載入資料

• Path 節點指定檔案位置（例如 /data/orders.csv）。
• Load from CSV 檔案讀取節點直接將 CSV 資料載入為結構化的 DataGrid。

[Path Node] "/data/orders.csv"
    │
    └─► [Load from CSV Node]
           │
           └─► DataGrid

等效的類 Python 虛擬碼：

orders_df = pd.read_csv("/data/orders.csv")

2. 篩選資料

• Filter 節點接收 DataGrid，並根據條件進行篩選（例如 order_total > 100）。

DataGrid
    │
    └─► [Filter Node] condition: order_total > 100
           │
           └─► Filtered DataGrid

等效的虛擬碼：

high_value_orders = orders_df[orders_df["order_total"] > 100]

3. 通過 HTTP API 傳送資料

• String 節點指定 webhook URI。
• HTTP Send Request 節點傳送篩選後的資料，資料會自動序列化為 JSON。

[String Node] "https://hooks.example.com/orders"
    │
    └─► [Send Request Node] method: POST, body: Filtered DataGrid

等效的虛擬碼：

import requests
payload = high_value_orders.to_dict(orient='records')
requests.post("https://hooks.example.com/orders", json=payload)

為什麼 Divooka 天然是資料驅動的：

• 高層抽象節點（Path、String、File I/O、Web Request）以透明的方式處理資料。
• 節點清晰地定義了依賴關係和流向，當輸入資料變化時會自動調整行為。
• 整個工作流都可以修改，而無需改動底層引擎程式碼，也無需重啟執行時環境。

親自動手：入門專案

要練習資料驅動設計，可以考慮以下適合初學者的專案：

• 功能開關儀表板：基於 YAML 的開關控制功能是否可見。
• 郵件路由自動化：用 SQLite 儲存路由規則，對收到的郵件進行分類。
• 程序化內容生成器：用 YAML 檔案配置生成資料輸出的參數。

每個專案都在強化同一點：你的引擎保持通用，由資料明確驅動所有行為。

結論

資料驅動設計最初是遊戲開發領域為實現快速迭代而提出的強大解決方案，使大型團隊能夠高效地構建和調整複雜軟體。如今，它的原則已跨越行業，惠及系統管理員、資料分析師、Web 開發者等眾多人群。

在 Divooka 這樣的工具中，資料驅動設計自然而然地得以體現——基於資料流的節點天生就將行為與實現分離，從而確保靈活性和穩健性。通過明確區分通用程式邏輯與外部驅動的資料，你就能構建出易於維護、適應性強且有韌性的軟體。

參考資料

• Wikipedia 上的 Data-driven programming（資料驅動程式設計）——不要與 Data-oriented design（面向資料的設計）混淆。
• Jason Gregory 的著作 Game Engine Architecture（目錄）。
• Richard Fabian 的著作 Data-Oriented Design（線上版）。

另請參閱：

• 知識庫中關於 SQL 和 SQLite 的頁面。