制限されたコンテキストとドメイン境界

Bounded Context （BC）は、単一のユビキタス言語、一貫したモデル、不変量が動作する明確な境界です。国境の内部では、用語は明確であり（"Bet"、 "Client"、 "Limit"）、コンテキスト外では契約（イベント/チーム）と通信し、他の人々の意味的な"尾の内側に引っ張らない。"スマートに選択された境界は、接続性を低減し、スケーリングを簡素化し、製品の進化を加速します。

1）なぜ国境が必要なのか

認知負荷低減。チームは1つのモデルと1つの言語で動作し、「一度にビジネス全体」ではありません。
不変量の分離。重要なルール（バランス≥ 0、ログイン一意性）は1つの場所にあり、集計によって保護されています。
変更管理。BC内のスキーム/ルールの進化は隣人を壊すことはありません-明示的な契約があります。
パフォーマンスと信頼性。BC内では、適切な一貫性モデルとストレージを選択できます。外部-非同期投影。

2）境界コンテキストを識別する方法

1.イベントストーミング：ドメインイベントを「何が起こったのか」を書き留め、コマンドを「何をしたらいいのか」、そして「ルールを保証する人」を集計します。

2.言語クラスタ：単語とルールが一貫して一致する場所-潜在的なBC。「Client」という単語が異なる（payerとplayer）を意味する場合-明確に異なるコンテキストがあります。

3.不変量と所有権：違反することはできませんし、誰が責任がありますか？それを保証することができるBC内の不変→。

4.バリューフロー：しばしば一緒に変化するグループステップ-これらは1つのBCの候補です。

5.組織構造：1つの部分が別々のKPIを持つ別のチームによって作られている場合-これはおそらく別のBCです（しかしその逆ではありません：組織構造は盲目的にモデルを指示するべきではありません）。

• 用語に関する紛争（「ベット」、「チケット」、「ラウンド」-異なる意味）。
• 最もホットな不変の「流れ」サービスを通じて。
• 異なるSLOと変化のペース。
• 原子性のためのモジュール間の「二重書き込み」。

3）典型的なコンテキスト（ドメイン例）

ID/KYC-登録、検証レベル、制限ステータス。
財布/元帳-残高、取引、準備金、通貨。
賭け/注文-受信、見積もり、計算。
ゲーム/ラウンド-ラウンドライフサイクル、結果。
ボーナス/プロモーション-accruals、 vager、変換。
支払い-入金/出金、支払いゲートウェイのステータス。
コンプライアンス/レポート-レポート、監査、規制ショーケース。
カタログ/プロバイダ統合-ゲーム、バージョン、プロバイダのステータス。
Analytics/Read Model-投影と実体化ビュー。

4）コンテキストマップ： BCsがどのように相互作用するか

• 顧客-サプライヤー。一方のBC（サプライヤー）はイベント/データを提供し、もう一方の（顧客）はモデルを調整します。
• コンフォーマスト。お客様はサプライヤーの言語とモデルをそのまま受け付けます（例：規制元帳）。
• パートナーシップ。2つのBCは、言語と契約を同期的に進化させます（多くの場合、1つのコマンド/ロードマップ）。
• 共有カーネル。共同でバージョン管理される共通の最低のsublanguage/library；慎重に使用してください。
• 腐敗防止層（ACL）。他人のモデルを自分の言語に変換する保護層。
• ホストサービス/公開言語を開きます。パブリックプロトコル/スキーム、バージョン管理およびドキュメント化。

練習：ACLと非同期イベントをデフォルトで使用します。Conformist-プロバイダが標準のShared Kernelを指示した場合のみ、最小かつ意識的に。

5）バインド=言語+モデル+不変量+ストレージ

• ユビキタス言語。例を含む用語の辞書。
• 集計と不変量。誰がルールを「保持」し、どのような操作が許可されています。
• 一貫性モデル。お金のための強い/CP、店頭のためのEC/原因。
• ストレージとインデックス。不変量とSLOに選択されています。
• 契約を終了します。イベント/コマンド、スキーマバージョン、配信SLO。

外部：直接SQL/テーブルの依存関係はありません。コミュニケーション-契約を通じて。

6）境界と整合性（PACELC）

BC内：不変量のモデルを選択します（ウォレット-ストロング、ベッティング-レセプションでストロング）。
BC間：ほとんどの場合、イベントや投影を通じて最終的な。同期検証が必要な場合、使用できないときに期限と失敗を伴う明示的なコマンド（「非表示」RESTコールではありません）。

7）腐敗防止層（ACL）

ACLのタスクは、BC内の他の誰かの言語と汚れたデータを許可することではありません。

スキーママッピング：外部'PaymentStatus=SRETEDED'→内部'LedgerEntry （type=Credit、 Reason=PSettle）'。
検証と濃縮：不変量の検証、タイムゾーンの正規化、通貨。
バージョン管理：'schema_version'外部コントラクトのサポート、下位互換性。
Idempotence： 'external_id'/'operation_id'による。
オブザビリティ：トレースタグ'source'、 'schema_version'、 'mapping_id'、 'poisonous'メッセージのDLQ。

8）境界とデータ： 所有権、予測、API

所有：誰が「真実」を所有していますか？所有者だけがレコードを変更します。BCの残りの部分-読み取りモデルとリンク。
投影：読み取りのための非正規化テーブル。イベントから更新されます。
API：コマンド（オーナーでのミューテーション）とリクエスト（プロジェクションを読む）。他の人のデータの「エンドツーエンド」アップデートはありません。

9）進化とバージョン

イベントとAPI-'schema_version'と互換性ポリシー（additive+fallback）。
BCによるBlue/Green：新しい契約'v2'は'v1'と並行して発行され、トラフィックは徐々に転送されます。
マイグレーション：大きな変更-新しい投影/サービス、読み取りの「二相スイッチ」。

10）境界テスト

契約テスト：BCが公開された契約（生産者テスト）に準拠していることを確認し、他の誰かの（消費者テスト）を正しく理解します。
プロパティベース：BC内の集計の不変量（バランス、限界、一意性）。
統合のカオス：遅延、順序外れ、重複、スキーマ進化；DLQおよび安全なredraveの存在。
NFRテスト：p95/peak load at the border （イベントサーバー/ACL）。

11）境界による観測性とSLO

メトリクス：イベント/コマンドのスループット、'projection_lag_ms'、' dlq_rate'、マッピングエラー、p95 API。
トレース：必須タグ'bc'、 'tenant_id'、 'event_id'、 'operation_id'、 'schema_version'。
アラート：投影の遅延を超え、コマンドの失敗を増やす、スキーマ「flap」（多くの'schema_mismatch'）。

12）複数のテナントおよび地域

'tenant_id'-境界上のすべてのイベントと投影のキー。
公平性：1テナントあたりの公開/再描画制限により、隣人のSLOを脱線させることから「騒々しい」状態を保ちます。
レジデンシー：BCデータは「ホーム」地域に住んでいます。cross-regional-集計/レポート。

13）アンチパターン（ぼやけた境界になる）

巨大な"コアサービス。"すべてが1つの場所で→トランザクション、ロングリリース、低い自治のための闘争。
表形式統合。SELECT外部テーブルへのライン→スキームに従って脆弱性と結合。
デュアルライト。同時に「、便宜のために」2つの紀元前に書き込む→不変量の不一致と妨害。
デフォルトではconformistです。「他人のモデルをそのまま受け入れる」→他人の意味の漏洩、進化の不可能性。
非表示同期コール。RESTは、明示的な契約と締め切りのない「どこかに」呼び出します→予期せぬ可用性への依存。

14）輪郭の例（口頭スキーム）

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15）国境選択のためのミニガイド

1.不変量を定式化し、誰がそれらを保証できるかを決定する。
2.辞書（10-20用語）を説明し、チームが同じ理解を持っていることを確認してください。
3.コンテキストマップとリレーションタイプを作成します。
4.ジョイント内およびジョイント内の一貫性モデルを解決します。
5.契約（イベント/コマンド）とACLを設計します。
6.観測可能性（メトリック/トレース/アラート）とDLQ/redriveの計画。
7.統合のための契約テストとカオスを実行します。
8.ガバナンスの修正：言語/スキームを所有している人、変更方法。

16）売り上げ前のチェックリスト

• 各BCには語彙、集計、不変量があります。
• 関係はコンテキストマップ上で定義され、契約は文書化されます。
• イベント/コマンドとACLによる統合、直接SQLの依存関係はありません。
• コマンド/イベントのidempotency；outbox/inboxとDLQがあります。
• 整合性モデル（intra/inter BC）固定およびテスト。
• スキーマバージョニングと互換性戦略（v1/v2）。
• Lag/error/performanceメトリックとアラートが設定されています。
• マルチテナンシーおよびデータレジデンシーポリシーが適用されます。
• Playbookの操作：schema-mismatch、 redrive、 rebuild projections。

17）クイックレシピ

お金と限度：CPとトランザクション、APIのみのコマンド、読み取りのための真実の結果としてのイベントでBCを分離します。
フィード/ディレクトリ：ECとBC、投影とキャッシュ、明示的な「新鮮さ」。
外部プロバイダとの統合：常にACL、イベント/コマンド、スキーマバージョニングを通じて。
チームの成長：1つのBCは1つのチームであり、チームには「言語所有者」と「不変量の管理者」がいます。
モノリス・リファクタリング：最初にコントラクトとACL、次に物理的分離。

結論

Bounded Contextは、単なる図ではなく、言語、ルール、進化の方法に関する作業合意です。境界をクリアすると、接続性が低下し、速度が変化し、システムの動作が予測可能になります。意味と不変性によって分離し、ACLの境界と契約を保護し、メトリクスですべてを測定します。ドメインとチームの急速な成長においても、アーキテクチャは柔軟かつ信頼性が維持されます。