Data Ownership：System of Recordと正式な事実を設計する
Data Architectureの出発点はdatabase製品ではありません。業務概念、所有者、正式記録、生成責任、利用契約、品質責任を決めます。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Data Owner・Steward・Custodianの責任
- System of Record・Reference・Projection
- Domain間data contract
体験55 · DATA OWNERSHIP（正式記録を決める）
同じ数値を表示する場所が複数あるDBは、設計として間違っているか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のdomain modelを確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
同じ数値を表示する場所が複数あるDBは、設計として間違っていると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
複数の値がある時、どれを正しいとするかが決まっていれば問題でしょうか？
ヒント2を見る
cacheを持つこと自体は誤りでしょうか？
もっと詳しく：この問いで使う専門用語
- System of Recordは、競合時に正式とみなす権威ある記録です。
- Data Ownerは、dataの意味・利用・品質・riskについて業務上の決定をする責任者です。
- Data Contractは、提供dataのschema・意味・品質・変更・SLOの約束です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Data Architectureはtable配置ではなく、意味、所有権、正本、品質、共有、保護、lifecycleを設計します。
System of Record、reference、master、projection、event、auditを区別し、競合時にどの記録を正とするか明確にします。
Data Owner、Steward、Custodian、Consumerの責任を分け、品質問題の決定権と修正経路を定義します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
System of Record
競合時に正式とみなす権威ある記録です。
複数copyの不一致を解決する基準になるためです。
資金変動はLedger記録から説明できる必要があります。
Data Owner
dataの意味、利用、品質、riskについて業務上の決定をする責任者です。
ITだけでは正しい業務意味を決められないためです。
口座、transfer、journal、auditごとにownerを定めます。
Data Contract
提供dataのschema、意味、品質、変更、SLOの約束です。
producer変更がconsumerを静かに壊すのを防ぐためです。
Payment Serviceが返すtransfer状態とerror意味を契約化します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
同じ値が複数ある前提で正を決める
copyがあること自体は悪ではありません。どこから生成し、どの鮮度で、矛盾時にどう直すかが未定義なcopyが危険です。
| Data role | 意味 | Minibank |
|---|---|---|
| System of Record | 最終的に正とする事実 | journalと取引記録 |
| Reference Data | 共通code・分類 | 口座種別、状態、error code |
| Master Data | 共有する中核entity | customer、account |
| Projection | 表示・検索用の派生 | cached_balance、dashboard集計 |
| Event | 起きた事実の通知 | TRANSFER_COMPLETED相当 |
| Audit Evidence | 変更・判断の証拠 | audit_logs |
Data accountability
| Role | 責任 |
|---|---|
| Business Data Owner | 意味、利用目的、quality、access、retentionを承認 |
| Data Steward | 定義、rule、issue、metadataを日常管理 |
| System Owner | application内で正しく生成・提供 |
| Custodian / Platform | 保存、暗号化、backup、availability |
| Consumer | 契約内利用、local copy、目的外利用を管理 |
| Privacy / Security | classification、legal basis、controlをreview |
Data Contract
API schemaだけでなく意味・品質・運用を契約化します。consumerがproducerの内部tableを直接読むと、変更と権限が結合します。
- business definitionとscope
- schema、identifier、unit、timezone、currency
- producerとauthoritative source
- quality ruleとSLO
- freshness・availability・volume
- classification・consent・allowed purpose
- change・version・deprecation
- issue連絡・replay・reconciliation
Minibank Data Ownership
Java DTOは新しいSystem of Recordではありません。PostgreSQL RPCの結果を運ぶmodelであり、正式記録の所在を変えません。
| Data | Authoritative owner | Derived / Consumer |
|---|---|---|
| Identity | Supabase Auth | customer profile、session |
| Customer / KYC | public customer domain | UI、admin、payment validation |
| Account state | account domain | payment、admin |
| Transfer request | payment domain | OTP、UI、audit |
| Journal | ledger domain | balance、trial balance、reconciliation |
| Learning content | docs library | static docs pages |
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
System of RecordとData Contractの考え方を読んだところで、教材内の参照元で実際のdomain modelを確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずTypeScript側のdomain schemaを見て、次にJava側のdomain projectionを見ます。どちらが正式記録を持つかを確かめましょう。
教材の参照元を確認する — Source Trail ↓TypeScript domain schema。
src/domain/Java domain projection。
services/payment-service/src/main/java/com/minibank/payment/domain/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ『どれが正式記録か』を決めることが、複数のcopyを持つこと自体より重要なのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「System of Record」という言葉を使って書いてみましょう。
ヒント2を見る
Java側のDTOが正式記録を複製していないか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
System of Record、Data Owner、Data Contractの3つを使って、複数のcopyがあっても安全に運用する方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- cacheを持つこと自体は誤りではないと説明できる
- Java層が正式記録を複製していないと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1最も新しいtimestampの値が正本ですか？
必ずしも違います。正式な更新権限と業務確定processでSoRを決めます。
Q2Data OwnerはDB管理者ですか？
通常は別です。Ownerは業務上の意味とrisk、Custodianは技術的保管を担います。
Q3cached balanceがLedgerと違う場合どうしますか？
Ledgerと正式ruleを基に差異を調査し、勝手な上書きでなく統制された訂正と照合を行います。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- Basel Committee — BCBS 239
risk data aggregationを支えるdata architecture、accuracy、integrity、completeness、timeliness
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/domain/TypeScript domain schema - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/table・constraint・schema ownership - 関連教材 — RELATED LESSON/docs/financial-it-stack関連教材の入口。System of Recordを含む金融IT stack