Learning Domain-Driven Design輪読会#5

Learning Domain-Driven Design  輪読会 #5  株式会社Showcase Gig   中島清貴
(@ahyataro)   #lddd_rindoku  Chapter 4. Integrating Bounded Contexts  

本資料は書籍「Learning Domain-Driven Design」のChapter4を意訳・要約したものです。  資料に記載の内容は @ahyataro が解釈した内容であり、原文の表現や内容と異なるものも含まれています  注意 

OverView  Chapter 4. Integrating Bounded Contexts  • Cooperation / 協力 
• Customer-Supplier / 顧客-供給者  • Separate Ways / 別々の道  • Context Map / コンテクストマップ  • Conclusion / 結論  • Exercises / エクササイズ 

Integrating Bounded Contexts / 境界づけられたコンテクストの統合  境界づけられたコンテクストは独立して進化できるが、システムの全体的な目標を達成するために統合する必要がある。境界づけられたコンテクスト間には常にタッチポイントがあり、これを契約と呼ぶ。  契約の必要性は、境界づけられたコンテクストのモデルと言語の違いから生じる。 

Integrating Bounded Contexts / 境界づけられたコンテクストの統合  この章では以下の3つの統合パターンについて説明する  • 協力  • 顧客-供給者 
• 別々の道 

4-1. Cooperation / 協力

Cooperation / 協力  • 協力パターンは、十分に確立されたコミュニケーションを持つチームによって形成される  • 一方のチームの成功が、もう一方のチームの成功に依存する  • パートナーシップと共有カーネルパターンがある 

Partnership / パートナーシップ  • パートナーシップモデルでは、境界づけられたコンテクスト間の統合がアドホックな方法で調整される  • 一方のチームが行ったAPIの変更がもう一方に伝わり、協力して適応する 

Partnership / パートナーシップ  • 統合の調整は双方向  • 各々のチームは各々のソリューションを選択できる  • 統合に問題が生じた場合は双方が協力して解決する  •
双方の仕事をブロックすることに関心を持たない  • パートナーシップモデルを成功させるには、確立されたコラボレーションプラクティス、高いレベルのコミットメント、チーム間の頻繁な同期が必要  • そのため地理的に分散したチームには向かない 

Shared Kernel / 共有カーネル  • 共有カーネルは、サブドメインの同じモデルまたはその一部が複数の境界づけられたコンテクストに実装されるパターン  •
全ての境界づけられたコンテクストのニーズを満たすように設計する必要がある  • 一貫性があることも重要 

Shared Kernel / 共有カーネル  • 共有モデルに加えられた変更は、全てのコンテクストに即座に影響する  • 変更の影響を最小限に抑えるには、共有するモデルを必要最低限にする  • コンテクスト境界を越えて渡されることを目的とした統合コントラクトとデータ構造の
みで共有カーネルが構成されることが理想  共有するスコープ 

Shared Kernel / 共有カーネル  • 単一リポジトリ内で実装する  ◦ 複数のコンテクストで共通のソースファイルを参照する  • 共有カーネル用のライブラリを作る 
• 共有カーネルを変更すると複数のコンテクストに影響が出るので、変更をトリガーにした統合テストが必要  実装方法 

Shared Kernel / 共有カーネル  • 重複コストと統合コストの違いはモデルの変動性によって異なる  • 頻繁に変更するほど統合コストは高くなる  • したがって共有カーネルは最も変化の激しいサブドメインであるコアサブドメインに適
用される  • 共有カーネルを導入することは、単一チームが境界づけられたコンテクストを所有するという原則に矛盾するため、慎重に検討が必要  ◦ 複数チームがひとつの共有カーネルの開発をすることになるので  共有カーネルの使いどころ 

Shared Kernel / 共有カーネル  • 地理的な制約や組織の政治のためにコラボレーションの問題があり、パートナーシップパターンができない場合  ◦ 共有カーネルのスコープを最小化することで、変更による影響範囲が制御され、変更ごとに統合テストを行うことで、統合時の問題を早期に検出できる 
• レガシーシステムの段階的なモダナイゼーションをしたい場合  ◦ このようなシナリオでは、共有コードベースは境界づけられたコンテクストに徐々に分解されるため、実用的な中間ソリューションになる  • 同じチームが担当する境界づけられたコンテクストを統合する場合にも役に立つ  ◦ このような場合、境界づけられたコンテキストのアドホックな統合(パートナーシップ)により、時間の経過と共に境界が「洗い流される」可能性がある  共有カーネルが適している場面 

4-2. Customer-Supplier / 顧客-供給者

Customer-Supplier / 顧客-供給者  • 供給者(上流)が顧客(下流)にサービスを提供するという関係性のパターン  • 「協力」の場合とは違い、両チームは独立して開発できる 

Customer-Supplier / 顧客-供給者  顧客-供給者パターンでは力関係が不均衡である場合がほとんどである。  このような力関係の違いに対処するためのパターンが以下の3つである  • 順応者  • 腐敗防止層  •
オープンホストサービス 

Conformist / 順応者  • 下流チームが上流チームのモデルを受け入れる関係性を順応者と呼ぶ  • 上流チームは下流チームのニーズをサポートすることはなく、独自のモデルに従って定義された統合契約を提供するだけ  • このような力の不均衡は、組織の外部にあるサービスプロバイダーとの統合時や、
組織内の政治によって引き起こされる 

Anticorruption Layer / 腐敗防止層  下流のコンテクストが上流に準拠することを避けたい場合、腐敗防止層を使うと上流のモデルを下流独自のニーズに合わせたモデルを変換できる 

Anticorruption Layer / 腐敗防止層  腐敗防止層の使いどころ  • 下流のコンテクストにコアサブドメインが含まれる場合  ◦ コアサブドメインのモデルには特別な注意が必要であり、供給者のモデルに準拠するとモデリングが妨げられる可能性がある 
• 上流のモデルが顧客にとって非効率的または不便である場合  ◦ レガシーシステムと統合するときによく見られる  • 供給者の契約が頻繁に変更される場合  ◦ 腐敗防止層によってモデルの頻繁な変更から保護できる 

Open-Host Service / オープンホストサービス  • 実装モデルの変更から顧客を保護するために、上流の供給者は実装モデルをパブリックインターフェースから切り離す  • 供給者のパブリックインターフェースはユビキタス言語に準拠せず、統合指向の言語で表現され、顧客にとって便利なプロトコルを公開する 

Open-Host Service / オープンホストサービス  • 境界づけられたコンテクストの実装モデルと統合モデルを分離することで下流のコンテクストに影響を与えることなく実装を自由に進化させられる  •
公開言語を複数バージョン公開できるので、顧客は新しいバージョンに徐々に移行できる 

4-3. Separate Ways / 別々の道

Separate Ways / 別々の道  • 別々の道は全くコラボレーションしないパターン  • チームが協力することを望まない、またはできない場合に発生する  • 複数の境界づけられたコンテクストで機能を複製する方が費用対効果が高い場合
がある  ◦ 例えばロギングフレームワークは複数コンテクストで必要となるが、各コンテクストで個別で実装したほうが統合の仕組みを考えるより低コストで済む  • コンテクスト同士のモデルの違いが大きく、腐敗防止層での変換が難しい場合に別々の道を進む方が費用対効果が高くなる 

Separate Ways / 別々の道  • コアサブドメインを統合する場合は別々の道を避けるべき  • コアサブドメインの実装を複製すると、最も効果的で最適化された方法で実装するという戦略に反することになる 

4-4. Context Map / コンテクストマップ

Context Map / コンテクストマップ  境界づけられたコンテクスト間の統合パターンを分析した後、それらを以下のようなコンテクストマップにプロットできる 

Context Map / コンテクストマップ  • 概要設計  ◦ システムコンポーネントとコンポーネントが実装するモデルの概要を示す  • コミュニケーションパターン 
◦ どのチームが共同作業を行っているか、どのチームがあまり親密でない統合パターンを好むかなどがわかる  • 組織の問題  ◦ 特定の上流チームの下流顧客がすべて腐敗防止層に頼っている、別々の道の全ての実装が同じチームに集中している、などの組織的な問題がわかる  コンテクストマップから以下のような貴重な戦略的洞察が得られる

Context Map / コンテクストマップ  • コンテクストマップが最初からプロジェクトに導入され、境界づけられたコンテクストの新規追加と更新が反映されることが理想  • コンテクストマップのメンテナンスは複数チームで共同で行うことが望ましい  •
Context Mapper というツールでコンテクストマップをコード管理できる 

Context Map / コンテクストマップ  • コンテクストマップの作成は困難な作業になる可能性があることに注意  • システムの境界づけられたコンテクストが複数のサブドメインを含む場合、複数の統合パターンが作用する可能性がある  •
境界づけられたコンテクストが1つのサブドメインに制限されている場合でも、サブドメインのモジュールが異なる統合戦略を必要とする、など複数の統合パターンが存在する可能性がある 

4-5. Conclusion / 結論

Conclusion / 結論  • パートナーシップ  ◦ アドホックな方法での統合  • 共有カーネル  ◦
重複モデルを共有することで統合  • 順応者  ◦ 顧客は供給者のモデルに準拠する  • 腐敗防止層  ◦ 顧客は供給者のモデルを自分のニーズにあったモデルに変換する 

Conclusion / 結論  • オープンホストサービス  ◦ 供給者は顧客のニーズに合わせて最適化された公開言語を実装する  • 別々の道  ◦
特定の機能を複製する方がコラボレーションして統合するよりも費用がかからない場合がある  • コンテクストマップ  ◦ 境界づけられたコンテクスト間の統合は、コンテクストマップにプロットできる  ◦ システムの概要設計、コミュニケーションパターン、組織の問題に関する洞察を提供する 

4-6. Exercises / エクササイズ

Exercises / エクササイズ  1. コアサブドメインに使用してはならない統合パターンはどれでしょう？  a. 共有カーネル  b. オープンホストサービス  c.
腐敗防止層  d. 別々の道 

Exercises / エクササイズ  2. 腐敗防止層を実装する可能性が高い下流サブドメインはどれでしょう？  a. コアサブドメイン  b. サポーティングサブドメイン  c.
汎用サブドメイン  d. bとc 

Exercises / エクササイズ  3. オープンホストサービスを実装する可能性が高い上流サブドメインはどれ　でしょう？  a. コアサブドメイン  b.
サポーティングサブドメイン  c. 汎用サブドメイン  d. bとc 

Exercises / エクササイズ  4. ある意味で境界づけられたコンテクストの所有権のルールに違反する統合   パターンはどれでしょう？  a. パートナーシップ  b.
共有カーネル  c. 別々の道  d. 統合パターンによって所有権のルールが破られることはない 

Learning Domain-Driven Design輪読会#5

Learning Domain-Driven Design輪読会#5

kyotak

Transcript