Business DomainとOperating Model：責任を組織・業務・ITで揃える
Domain境界はtableやmicroserviceの分割ではありません。顧客・商品・契約・決済・会計などの業務責任、意思決定権、data ownership、運用責任を一体で定義します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Business DomainとBounded Context
- Operating Modelと意思決定権
- Product TeamとControl Functionの協働
体験50 · DOMAIN / OPERATING MODEL（責任を揃える）
Domain（業務領域）の境界は、組織図やチーム名と必ず一致させるべきか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のdomain modelを確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
Domain（業務領域）の境界は、組織図やチーム名と必ず一致させるべきだと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
同じ『account』という言葉が、複数の別の意味で使われることはないでしょうか？
ヒント2を見る
domainの境界は、誰が判断し誰が責任を持つかから決まるでしょうか？
もっと詳しく：この問いで使う専門用語
- Business Domainは、固有の目的、責任、用語、ruleを持つ業務領域です。
- Operating Modelは、人・process・decision・information・technologyをどう組み合わせて運営するかです。
- Federationは、共通方針を保ちながら各domainへ実行権限を配る形です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Business Domainは一貫した責任、用語、rule、data ownershipを持つ業務境界です。
Operating Modelは中央集権か分散かという二択ではなく、標準化と自律性を責任ごとに設計します。
境界をservice名だけで決めず、誰が判断し、結果に責任を持ち、例外を処理するかから定義します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Business Domain
固有の目的、責任、用語、ruleを持つ業務領域です。
責任の重複やdataの意味の衝突を減らすためです。
Customer、Payment、Ledger、Risk、Auditなどに分けて検討できます。
Operating Model
人、process、decision、information、technologyをどう組み合わせて運営するかです。
構造だけでなく日々の判断と連携を機能させるためです。
Paymentの変更とLedger統制の承認関係を定義します。
Federation
共通方針を保ちながら各domainへ実行権限を配る形です。
全社一貫性と現場速度を両立するためです。
共通security・audit標準の下で各教材領域を自律改善します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
Domainを責任で切る
同じ『account』でも顧客口座、認証account、会計勘定は別の意味です。共有語を無理に1つの巨大modelへ統合せず、contextごとの意味と変換を定義します。
| Domain候補 | 所有する業務事実 | 他domainとの契約 |
|---|---|---|
| Customer | 本人、関係、KYC状態 | verified statusを提供 |
| Account | 口座契約、状態、利用可能性 | active accountを提供 |
| Payment | 依頼、認証、実行状態 | posting要求と結果 |
| Ledger | 勘定、仕訳、会計残高 | balanced journalと照会 |
| Operations | incident、case、reconciliation | issueとresolution |
| Identity | credential、session、actor | authenticated principal |
Operating Modelの6要素
- Outcome：domainが達成する顧客・業務結果
- Decision rights：誰がrule、data、API、riskを決めるか
- People：業務、engineering、security、data、operationsの能力
- Process：企画から運用・廃止まで
- Information：所有data、quality、sharing contract
- Control：承認、職務分離、metric、audit、escalation
Federated governance
共通化しすぎると遅くなり、自治しすぎると相互運用不能になります。再利用価値、risk、変更速度から境界を決めます。
| 全社で共通 | Domainで自治 |
|---|---|
| Identity・security baseline | 業務ruleと顧客体験 |
| Audit・data classification | domain modelとAPI detail |
| Observability・incident severity | SLIと運用dashboard |
| Technology lifecycle・supply chain | 許可範囲内のframework選択 |
| Architecture repository・exception process | delivery roadmap |
Minibankの責任境界をreviewする
現在の小規模repositoryでは同じ人が複数roleを担えても、成果物上の責任は分けます。誰が変更を承認し、誰が本番異常へ対応するかが曖昧ならarchitectureは未完成です。
- 01Business ownerが振込ruleと顧客結果を定義
- 02Payment teamがAPI・状態・冪等性を所有
- 03Ledger ownerが会計ruleと仕訳を承認
- 04Securityがactor・権限・threatをreview
- 05OperationsがSLI・alert・recoveryを準備
- 06Data ownerが意味・品質・retentionを管理
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Business DomainとOperating Modelの考え方を読んだところで、教材内の参照元で実際のdomain modelを確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずTypeScript側のdomain modelを見て、次にJava側のdomainを見ます。同じ概念がdomainごとにどう表現されるかを確かめましょう。
教材の参照元を確認する — Source Trail ↓現在のTypeScript domain model。
src/domain/Java Payment domainとlayer。
services/payment-service/src/main/java/com/minibank/payment/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ同じ『account』という言葉でも、顧客口座・認証account・会計勘定では別の意味として扱う必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Business Domain」という言葉を使って書いてみましょう。
ヒント2を見る
TypeScriptとJavaで同じ概念が別の型として存在する理由を考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Business Domain、Operating Model、Federationの3つを使って、domain境界と責任分担の関係を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- domain境界は組織図と必ずしも一致しないと説明できる
- 誰が意思決定権を持つかがdomain設計の基準だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1domain境界は組織図どおりに決めますか？
必ずしも一致しません。責任、rule、用語、dataの整合性から決めます。
Q2自律teamなら全社標準は不要ですか？
不要ではありません。identity、security、audit、data contractなど横断標準が必要です。
Q3責任境界を検証する質問は何ですか？
誰が決定し、誰がdataを正し、障害と例外の結果に誰が責任を持つかです。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- BIAN — Service Landscape
銀行業務capabilityをService Domainとして整理する業界参照構造
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
- 金融庁 — 金融機関のITガバナンスに関する論点・プラクティス
経営戦略、IT戦略、DX戦略、次世代architecture、投資・risk・人材の統合
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/domain/現在のTypeScript domain model - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/src/main/java/com/minibank/payment/Java Payment domainとlayer - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/DB内のschema・責任境界