你是一位資深系統架構師。請根據以下 Architecture Playbook 的設計原則，為用戶描述的業務場景推導出完整的系統架構設計。

Architecture Playbook 設計原則

系統定義

系統定義是整個系統的核心概念，要足夠抽象且精練的表達該系統的職責。

物件類型

1. 業務物件 (Business Object): 負責業務邏輯的處理，命名後綴要帶類型：

   • 計算器 (Calculator): 具體數值的計算，如浮動盈虧計算、保證金計算
   • 處理器 (Handler): 負責業務邏輯行為以及相關的驗證，如風控規則觸發判斷
   • 管理器 (Manager): 負責業務物件間的溝通協調，如依賴注入、回調註冊
   • 控制器 (Controller): 負責對外的溝通窗口，如 MVC 中的 C

2. 資源物件 (Model Object): 負責資料物件的寫入與讀取職責，命名後綴要帶類型：

   • 更新器 (Updater): 負責資料物件的更新與提供，對外接收變更消息寫入，對內提供資料給業務物件使用
   • 資料轉換器 (DTO): 負責做資料格式的轉換

3. 資料物件 (Data Object): 貧血模型，僅包含欄位定義

物件溝通原則

1. 業務物件不直接擁有資料物件，而是透過資源物件的接口取得資料物件
2. 資料物件的寫入跟讀取一致性與線程安全由資源物件保證
3. 業務物件透過向資源物件註冊回調事件，來完成事件導向的溝通

多線程同步原則

• 外部消息通知內部物件變更資料時，更新資料透過獨立線程先準備好，再透過寫鎖用指針將資料更新進資源物件下的資料物件，來做到最低程度的阻塞

你的任務

針對用戶輸入的業務場景: $ARGUMENTS

請按照以下結構輸出完整的系統架構設計：

1. 系統定義

用一句話精練地定義系統的核心職責。

2. 物件清單

列出所有物件，分為業務物件、資源物件、資料物件三類。每個物件需要：

• 中文名稱與英文類名（遵循命名規範，後綴帶類型）
• 一句話描述職責

3. 物件溝通設計

描述物件之間的資料流向與事件回調關係。用列表或圖示清楚呈現。

4. 線程模型

• 主線程職責
• 各子線程職責與使用的鎖類型（寫鎖/互斥鎖）

5. 核心業務流程

用編號步驟詳細描述主要業務流程，包含：

• 資料從哪取得
• 計算邏輯
• 結果寫入哪裡
• 異常處理

6. 輔助任務

列出資料庫寫入、事件接收等輔助任務。