DDD は大規模システムでどのように動作しますか? (Ddd 3)

まず間違った質問をやめましょう

初日には、Book モデルが 1 つだけありました。次に、営業チームは価格を尋ね、出荷チームは配達期間を尋ね、マーケティング キャンペーン情報を追加しました。半年後、同じ教室は誰も完全には理解できない物体と化した。問題は、本が成長していることではありません。さまざまなビジネス上の意図が単一のモデルにロードされました。

大規模なシステムをマイクロサービスに分割することは、DDD を実装することではありません。まず、ビジネスのどの部分で言語、意思決定、変化のリズムが異なるのかを理解する必要があります。そうしないと、モノリスではなく、より高価な分散モノリスが作成されます。```text Tek model → herkesin ihtiyacını taşımaya çalışır → model gerilimi

Satış bağlamı → fiyat ve müşteri kredisi Kargo bağlamı → teslimat adresi ve paket Katalog bağlamı → başlık, ISBN ve metaveri

## 最初に説明した概念```text
📦 Bounded Context
Bir modelin, dilin ve kuralların kendi içinde tutarlı kaldığı açık sınır.

📦 Context Mapping
İki bağlamın veri, güç ve sözleşme ilişkisini bilinçli olarak tanımlama pratiği.

📦 Upstream / Downstream
Veriyi veya sözleşmeyi sağlayan taraf upstream; ona bağımlı tüketen taraf downstream'dir.

📦 Anti-Corruption Layer (ACL)
Dışarıdaki modelin kavramlarını kendi domain'inize sızmadan çeviren katman.
```コンウェイの法則を簡単に説明すると、次のとおりです。組織がコミュニケーションを行うのと同じように、ソフトウェアは時間の経過とともにその構造を反映します。境界コンテキストはマイクロサービスではありません。まず、モジュール式モノリス内で別個の言語、所有権、およびコード境界として存在できます。

## 全体像```text
                         Şirket
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
    Katalog              Satış                Kargo
       │                    │                    │
     Book               Customer             Recipient
       │                    │                    │
       └──────── OrderConfirmed event ────────┘
                            │
                         Outbox
                            │
                          Broker
                            │
                     Delivery projection
```この図には物理サービスの数は含まれていません。これは、言語、所有権、および変更がどの国境で行われるかを示します。

## 唯一の真のモデルの検索が失敗するのはなぜですか?

書籍カタログの場合、これはタイトル、著者、ISBN です。貸出中の場合、それは棚にある物理的なコピーです。 SKUと価格はセール中です。これらすべてを 1 つの `Book` クラスに結合することは再利用ではなく、異なるインテントを結合することになります。同じ緊張が `Customer` にも見られます。営業チームはクレジット情報と請求先情報を要求しますが、貨物は住所と配送希望のみを要求します。```text
❌ Unified Customer
creditLimit + invoiceAddress + deliveryWindow + marketingConsent + ...

✓ Sales.Customer
creditLimit + billingProfile

✓ Shipping.Recipient
deliveryAddress + deliveryWindow
```問題はオブジェクトの数ではありません。これは、異なるチームが異なる理由で同じモデルを改造することです。影響を受けるコンテキスト `k` の数が増えると、この変更コストは少なくとも O(k) になります。依存関係が急増すると、テストと調整のコストが急速に増加します。

## 境界コンテキスト: 最初にジョブの言語で境界を描画します

境界についてテクニカル レイヤーやデータベース テーブルを監視しないでください。次の信号に注意してください。

1. 会議では同じ単語でも意味が異なりますか?
2. `if (shipping)`、`if (sales)` などの特殊なケースがモデル内で複数発生しますか?
3. チームは常に同じ変更をお互いに待っていますか?
4. ドメインの所有権、成功の尺度、変化のリズムは不明確ですか?

ここでコンウェイの法則に注意してください。システムの通信境界は、多くの場合、組織の通信方法を反映します。チームが独立した意思決定を行うことが期待される場合、そのチームのモデルと展開制限は可能な限り独立したものである必要があります。これは技術的な目標ではなく、所有権の決定です。

## モノリスから始めます。結果としてマイクロサービスを参照

境界コンテキストを検証する最もリスクの低い方法は、モジュール式モノリスを使用することです。コンテキストには、独自のアプリケーション/ドメイン/インフラストラクチャ コンポーネント、データ アクセス、および明示的なコントラクトがあります。ただし、分散呼び出しの運用コストはまだ負担していません。```text
Catalog module ── published contract ──► Sales module
Sales module   ── domain event ─────────► Shipping module

Her module: kendi dilini, use case'lerini ve sahipliğini korur
```マイクロサービスへの移行は、独立したスケーリング、独立したデプロイメント、異なるセキュリティ境界、または真のチームの自律性など、ニーズが証明されている場合にのみ意味があります。境界のあるコンテキスト = マイクロサービスの同等性が、早期にデプロイする最も一般的な理由です。

## コンテキスト マッピング: 統合は偶然であってはなりません

コンテキスト間の関係は、API エンドポイントではなく、力のバランスとモデルの汚染によって決まります。

|ステータス |適切な戦略 |なぜ |
| --- | --- | --- |
|レガシーモデルカオス | ACL |外部言語がドメインに漏洩するのを防ぎます |
|多数の消費者 |オープンホストサービス + 公開言語 |内部モデルではなく、バージョン管理されたコントラクトを共有します。
|あなたは上流に影響力を持っていません、モデルはクリーンです |適合者 |不要な翻訳レイヤーをインストールしません |
|小さくてめったに変更されない共通部分 |共有カーネル、最後の手段 |コーディネート費用承ります |

ACL の例では、カーゴ コンテキストは、レガシー ERP の `CUST_TIER=7` フィールドを独自の `DeliveryEligibility` コンセプトに変換します。 ERP という用語は貨物の分野には当てはまりません。この層は追加コードのコストとなります。その代わり、外部システムが変化しても、その影響は単一の変換点に留まります。

## イベント、送信ボックス、および最終的な整合性

コンテキストは別のコンテキストのデータベースを読み取るべきではありません。営業部門が注文を確認すると、`OrderConfirmed` イベントを発行できます。カーゴはこれに基づいて独自の配送ビューを生成します。イベントは同期呼び出しを完全に禁止するものではありません。ただし、独立したワークフローにおける時間的依存性は軽減されます。```text
Sales transaction
  → Order'ı kaydet
  → Outbox'a OrderConfirmed yaz
  → Commit

Relay → Broker → Shipping consumer → Delivery projection
```ブローカーとデータベースは同じ ACID トランザクションを共有しないため、送信ボックスが必要です。注文記録がある場合は、ブロードキャストされるイベントもあります。リレーは再試行する可能性があります。コンシューマは重複したイベントを受信する可能性があるため、冪等である必要があります。最終的な一貫性はエラーではなく、製品が許容しなければならない目に見える時間枠です。

## このデザインの価格

コンテキストの境界には、より多くの合意、可観測性、バージョン管理、チームの規律が必要です。新しいコンシューマはそれぞれ O(1) コードを追加するだけではありません。また、ダッシュボード、アラーム、再試行、所有権、統合テストも追加されます。したがって、最良のフロンティアとは、最も多くのサービスを生み出すフロンティアではありません。この制限こそが、変更のコストを実際に削減するものなのです。

## 誤った信頼を生み出す一致```text
❌ Bounded Context = mikroservis
✓ Bounded Context önce dil, sahiplik ve model sınırıdır.

❌ Tek model = tutarlılık
✓ Her bağlamın kendi tutarlı modeli olabilir.

❌ Shared Kernel = yeniden kullanım
✓ Shared Kernel ortak değişim ve koordinasyon maliyetidir.

❌ REST çağrısı = entegrasyon stratejisi
✓ Sözleşme, sahiplik ve hata davranışı stratejidir.

❌ Eventual consistency = hata
✓ Doğru tasarlanırsa bağımsız iş akışının bilinçli trade-off'udur.

戦略的設計のチェックリスト

1. 同じ単語の異なる意味はどこから始まるのでしょうか?
2. 言語の所有者、所有者、各コンテキストの成功基準は明確ですか?
3. この境界はモジュラーモノリス内で最初に検証できますか?
4. アップストリーム モデルはドメインに直接侵入しますか。 ACLは必要ですか?たとえば、フロー ERP → ACL → Shipping では、CUST_TIER=7 を貨物のコンセプト DeliveryEligibility に変換する必要があります。
5. 共有コントラクトには下位互換性があり、バージョン管理されていますか?
6. 注文がコミットされた後にブローカーがクラッシュした場合はどうなりますか? Outbox は、発行されるレコードとイベントを同じローカル トランザクションに書き込みます。リレー ブローカーが戻ってくると、安全に再試行します。
7. イベントの遅延、複製、および再生に関する製品および運用に関する決定事項はありますか?

コードは数行増えるだけではありません。監視、アラーム、再試行、および操作のオーバーヘッドも追加されます。コードの増分は O(1) のように見えますが、運用コストは直線的に増加しません。サービスの数ではありません。互換性とエラー分離を測定します。

この記事で覚えておくべきこと

1. 大規模システムには単一の正しいモデルはありません。それぞれの境界コンテキストには、独自のビジネス上の現実があります。
2. マイクロサービスは戦略的フロンティアの始まりではありません。時にはそれが物理的な結果であることもあります。
3. コンテキスト マッピングは統合の技術的な詳細ではありません。契約により、権限とモデル保護の決定が可視化されます。
4. イベントと送信ボックスは、コンテキストの独立性を安全に維持するために使用されます。

アーキテクチャ上の境界は、コードが停止する前に、どの言語で、誰の責任の下で意思決定が行われるかです。

最後のセクションでは、DDD の運用期間、つまりイベント ストーミング、レガシー変換、破損防止レイヤー、および変更の安全な移行について検討します。