Application Boundaries：Monolith・Module・Serviceを責任で選ぶ
分割数ではなく、業務整合性、変更単位、data ownership、team認知負荷、failure isolationから境界を設計します。Microservicesは目標ではありません。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- 高凝集・低結合の実務的意味
- Modular MonolithとMicroserviceの選択
- 境界を越える不変条件の扱い
体験53 · APPLICATION BOUNDARIES（責任で境界を選ぶ）
Microservicesのように多く分割するほど、結合度は下がるか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の境界設計を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
Microservicesのように多く分割するほど、システムの結合度は下がると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
分割すると、結合は消えるのでしょうか、それとも形を変えるのでしょうか？
ヒント2を見る
同時に確定しなければならない条件を、別のserviceへ分けてよいでしょうか？
もっと詳しく：この問いで使う専門用語
- Bounded Contextは、用語とmodelが一貫する責任境界です。
- Invariant Boundaryは、同時に守るべき条件をatomicに確定できる境界です。
- Couplingは、ある変更や障害が別の部分へ影響する強さです。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Application境界はdeploy単位ではなく、変更理由、業務責任、data ownership、一貫性、障害範囲から設計します。
Monolith、Modular Monolith、Microservicesにはそれぞれ適用条件があり、分割数は成熟度の尺度ではありません。
金融不変条件を跨ぐ分割はdistributed transaction、重複、順序、補償、照合という新しい責任を生みます。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Bounded Context
用語とmodelが一貫する責任境界です。
同じ言葉の異なる意味を無理に1つへ統合しないためです。
PaymentのtransferとLedgerのjournalは関連しますが責任が異なります。
Invariant Boundary
同時に守るべき条件をatomicに確定できる境界です。
分割により金融上の正しさを壊さないためです。
借方・貸方・transfer状態の確定境界を検討します。
Coupling
ある変更や障害が別の部分へ影響する強さです。
見えない依存がrelease速度と安定性を下げるためです。
Next.jsがDB内部schemaへ直接依存する範囲を確認します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
境界の評価軸
| 軸 | 同じ境界へ置くsignal | 分けるsignal |
|---|---|---|
| Business rule | 同じ不変条件で同時変更 | 異なるlanguage・owner |
| Transaction | 強い原子性が必須 | eventual consistencyを許容 |
| Change | 同時releaseが多い | 独立した速度・roadmap |
| Scale | 同じ負荷特性 | 一部だけ極端にscale |
| Failure | 一緒に止まる方が安全 | blast radiusを隔離 |
| Team | 1teamが理解・運用可能 | 認知負荷・権限を分けたい |
3つの選択肢
| 形 | 強み | 代償 |
|---|---|---|
| Layered Monolith | 単純なdeployとtransaction | 境界が曖昧だと巨大化 |
| Modular Monolith | 同一processで明確なmodule | 規律とmodule testが必要 |
| Microservices | 独立release・scale・failure isolation | network、data分散、observability、運用cost |
境界を越える整合性
資金移動と仕訳のように強く一体であるものを、流行だけで別DBへ分離するとdistributed transactionが必要になります。境界は不変条件から逆算します。
- 01各domainのSystem of Recordを決める
- 02同期して守る不変条件を最小化
- 03eventへidentity・version・occurred timeを持たせる
- 04consumerは重複・順序逆転・欠落へ耐える
- 05reconciliationで最終状態を検証
- 06補償・再処理・人手caseを設計
Minibankの境界評価
現在のPayment Serviceは薄いGatewayとして段階追加されています。境界の妥当性はcode量ではなく、目標operating modelと移行成果で評価します。
- Next.jsからJavaへHTTP境界を増やす価値は、独立運用・人材・将来責任で説明する
- 金融ruleをJavaとPostgreSQLへ重複させない
- Payment Serviceはcaller tokenを保ち既存認可へ接続
- Ledgerを別serviceへ分ける前に原子性と照合を設計
- Docsはproduct runtimeから論理分離されるが同一applicationで配布
- 分割後のSLO、trace、on-call、costを事前に見積もる
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Bounded ContextとInvariant Boundaryの考え方を読んだところで、教材内の参照元で実際の境界設計を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず既存TypeScript側のservice境界を見て、次にJava側がどこまで委譲しているかを見ます。境界と不変条件の関係を確かめましょう。
教材の参照元を確認する — Source Trail ↓既存TypeScript service境界。
src/services/Java layer・domain境界。
services/payment-service/src/main/java/com/minibank/payment/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ境界を『同時に確定しなければならない不変条件』から逆算して設計する必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Invariant Boundary」という言葉を使って書いてみましょう。
ヒント2を見る
PaymentとLedgerがなぜ同じtransactionで確定するのか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Bounded Context、Invariant Boundary、Couplingの3つを使って、application境界の設計方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 分割は結合をなくすのではなく形を変えると説明できる
- 不変条件から境界を逆算する必要があると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1Microservicesへ分割すれば結合はなくなりますか？
なくなりません。network contract、data、運用、組織の結合へ形が変わります。
Q2境界を決める重要な質問は何ですか？
何が一緒に変わり、何を一緒に確定し、誰が責任を持ち、どこまで独立障害にしたいかです。
Q3Minibankで分割前に証明すべきことは何ですか？
idempotency、順序、補償、照合、観測、障害時の顧客結果です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
- BIAN — Service Landscape
銀行業務capabilityをService Domainとして整理する業界参照構造
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/services/既存TypeScript service境界 - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/src/main/java/com/minibank/payment/Java layer・domain境界 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/DB transaction内に残る不変条件