各 Phase 對應服務清單

這份文件的重點，是把 Phase 1 到 Phase 5 從抽象藍圖落到具體服務邊界。

原則不是每個 phase 都暴增服務數量，而是每一階段都增加剛好足夠的系統能力。

Phase 1：建立最小平台骨架

必要服務

• instrument-master-service
• config-service
• market-data-vendor-connector
• historical-loader
• normalizer
• raw-archive-writer
• strategy-runtime
• risk-engine
• execution-gateway

角色說明

• instrument-master-service: 管理 instrument_id、symbol mapping、market/venue 基本資訊
• config-service: 管理策略設定、broker 設定、風控參數
• market-data-vendor-connector: 接入至少一條 live market data source
• historical-loader: 匯入歷史資料，供 replay 與回測使用
• normalizer: 把來源資料轉成 canonical events
• raw-archive-writer: 保留 raw immutable log
• strategy-runtime: 讓策略只吃 canonical events
• risk-engine: 執行基本 pre-trade checks
• execution-gateway: 統一 broker abstraction

先不要急著做

• 太細的 microservice 拆分
• 複雜 portfolio engine
• 進階 data quality 平台

Phase 2：統一 replay 與 research

新增服務

• replay-service
• bar-aggregator
• indicator-engine
• data-quality-monitor

角色說明

• replay-service: 將 historical data 重播為與 live 相同的事件介面
• bar-aggregator: 根據 event time 與 session 規則聚合 bars
• indicator-engine: 從 canonical events 產出可重用指標與特徵
• data-quality-monitor: 偵測 gap、duplicate、stale、late event

成熟化重點

• strategy runtime 不知道自己吃的是 replay 還是 live
• bars 有明確聚合規則與 finalize 規則
• data quality 不再只是人工看圖

Phase 3：治理與分析層成形

新增服務

• schema-registry 或等價 schema 管理元件
• analytics-loader
• workflow-orchestrator
• metrics-exporter
• alert-router

角色說明

• schema-registry: 管理 canonical schema version 與相容性
• analytics-loader: 將 canonical / derived data 匯入 ClickHouse
• workflow-orchestrator: 管 daily ingest、backfill、recompute、quality jobs
• metrics-exporter: 暴露服務層與資料層 metrics
• alert-router: 將資料品質與系統異常送到告警管道

成熟化重點

• backfill 與 daily jobs 不再靠一堆散落 script
• analytics 與 operational query 開始正式分層
• 各 topic/table/dataset 有更清楚 owner 與用途

Phase 4：營運與交易成熟化

新增服務

• fill-reconciler
• position-reconciler
• account-snapshot-service
• ops-control-service
• vendor-divergence-monitor

角色說明

• fill-reconciler: 對帳 order、fill、position 的一致性
• position-reconciler: 比對 internal 與 broker positions
• account-snapshot-service: 產出 account / portfolio snapshots
• ops-control-service: 提供 kill switch、strategy on/off、stale data guard
• vendor-divergence-monitor: 比對不同 source 的行情差異

成熟化重點

• production 不只是能下單，而是能安全營運
• incidents 可以回放，也可以對帳與追責
• execution truth 開始被正式管理

Phase 5：資料資產與平台治理

新增服務或平台元件

• metadata-catalog
• lineage-service
• feature-dataset-registry
• research-dataset-builder

角色說明

• metadata-catalog: 管理資料資產描述、owner、用途、文件
• lineage-service: 追蹤 topic、table、dataset 的上下游依賴
• feature-dataset-registry: 管理 feature / factor dataset 的版本與定義
• research-dataset-builder: 建立可重現的研究資料集

成熟化重點

• 平台不只是能跑，而是變成公司正式研究資產
• 新人與新策略可更快理解與接入既有資料資產
• 資料與服務開始有 ownership、catalog、lineage

最小服務集合建議

如果你希望避免一開始服務數量爆炸，可以先把多個角色合併成較少進程：

• control-plane: instrument + config
• ingestion-plane: connectors + normalizer + raw writer
• compute-plane: replay + bar + indicator + quality
• trading-plane: strategy + risk + execution
• ops-plane: metrics + alerts + reconciliation

等邊界穩定，再逐步拆細。