CQRSアーキテクチャ（申告データ向け）

申告データに対しては、CQRS (Command Query Responsibility Segregation) パターンを採用し、「書き込み（Command）」と「読み取り（Query）」の責務を分離します。

採用理由

目的	CQRSによる実現
履歴管理	全ての変更操作をコマンドとして記録し、任意時点への復元を可能にする
監査証跡	「誰が」「いつ」「何を」変更したかを完全に追跡可能
データ分離	従業員入力データと管理者入力データを明確に分離して管理
読み取りパフォーマンス	表示用のデータモデル（Read Model）を最適化し、高速なクエリを実現

アーキテクチャ構成図（スナップショット方式）

IMPORTANT

本システムは完全なイベントソーシングは採用せず、スナップショット方式を採用する（下記「イベントソーシングの採用判断」参照）。上図の Write Model はイベントストアではなく、画面遷移ごとのスナップショットを JSONB として保存する。

Command Side

• 申告データの作成・更新・削除はすべてコマンドとして処理
• 各コマンド実行時に、申告データ全体のスナップショットをJSONBとして保存
• スナップショットには操作者（従業員/管理者）と日時を記録

Query Side

• 表示用の最新データは Read Model として別途管理
• コマンド実行後に Read Model を同期的に更新（結果整合性ではなく即時整合性を優先）

---

イベントソーシングの採用判断

観点	イベントソーシングあり	スナップショット方式（採用）
履歴の粒度	全操作を完全に記録	画面遷移時のスナップショットのみ
復元の柔軟性	任意の操作単位で復元可能	スナップショット単位での復元
実装の複雑さ	高（イベントスキーマの進化管理が必要）	中（スナップショットの管理のみ）
ストレージ量	多い（全イベントを保持）	少ない（スナップショットのみ）

採用方針: スナップショット方式を採用する。年末調整の業務特性（年度単位のライフサイクル、変更頻度が低い、監査証跡はスナップショット粒度で十分）に対して、イベントソーシングの複雑さ（イベントスキーマの進化管理、Read Modelの再構築等）は正当化できない。