Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Learning Domain-Driven Design輪読会#5

kyotak
June 02, 2022
240

Learning Domain-Driven Design輪読会#5

kyotak

June 02, 2022
Tweet

Transcript

  1. Learning Domain-Driven Design
 輪読会 #5
 株式会社Showcase Gig 
 中島 清貴

    (@ahyataro) 
 #lddd_rindoku
 Chapter 4. Integrating Bounded Contexts 

  2. OverView
 Chapter 4. Integrating Bounded Contexts
 • Cooperation / 協力


    • Customer-Supplier / 顧客-供給者
 • Separate Ways / 別々の道
 • Context Map / コンテクストマップ
 • Conclusion / 結論
 • Exercises / エクササイズ

  3. Partnership / パートナーシップ
 • 統合の調整は双方向
 • 各々のチームは各々のソリューションを選択できる
 • 統合に問題が生じた場合は双方が協力して解決する
 •

    双方の仕事をブロックすることに関心を持たない
 • パートナーシップモデルを成功させるには、確立されたコラボレーションプラクティ ス、高いレベルのコミットメント、チーム間の頻繁な同期が必要
 • そのため地理的に分散したチームには向かない

  4. Shared Kernel / 共有カーネル
 • 共有カーネルは、サブドメインの同じ モデルまたはその一部が複数の境 界づけられたコンテクストに実装され るパターン
 •

    全ての境界づけられたコンテクストの ニーズを満たすように設計する必要 がある
 • 一貫性があることも重要

  5. Shared Kernel / 共有カーネル
 • 単一リポジトリ内で実装する
 ◦ 複数のコンテクストで共通のソースファイルを参照する
 • 共有カーネル用のライブラリを作る


    • 共有カーネルを変更すると複数のコンテクストに影響が出るので、変更をトリガー にした統合テストが必要
 実装方法

  6. Shared Kernel / 共有カーネル
 • 重複コストと統合コストの違いはモデルの変動性によって異なる
 • 頻繁に変更するほど統合コストは高くなる
 • したがって共有カーネルは最も変化の激しいサブドメインであるコアサブドメインに適

    用される
 • 共有カーネルを導入することは、単一チームが境界づけられたコンテクストを所有す るという原則に矛盾するため、慎重に検討が必要
 ◦ 複数チームがひとつの共有カーネルの開発をすることになるので
 共有カーネルの使いどころ

  7. Shared Kernel / 共有カーネル
 • 地理的な制約や組織の政治のためにコラボレーションの問題があり、パートナーシップパ ターンができない場合
 ◦ 共有カーネルのスコープを最小化することで、変更による影響範囲が制御され、変更 ごとに統合テストを行うことで、統合時の問題を早期に検出できる


    • レガシーシステムの段階的なモダナイゼーションをしたい場合
 ◦ このようなシナリオでは、共有コードベースは境界づけられたコンテクストに徐々に分 解されるため、実用的な中間ソリューションになる
 • 同じチームが担当する境界づけられたコンテクストを統合する場合にも役に立つ
 ◦ このような場合、境界づけられたコンテキストのアドホックな統合(パートナーシップ)に より、時間の経過と共に境界が「洗い流される」可能性がある
 共有カーネルが適している場面

  8. Anticorruption Layer / 腐敗防止層
 腐敗防止層の使いどころ
 • 下流のコンテクストにコアサブドメインが含まれる場合
 ◦ コアサブドメインのモデルには特別な注意が必要であり、供給者のモデルに準 拠するとモデリングが妨げられる可能性がある


    • 上流のモデルが顧客にとって非効率的または不便である場合
 ◦ レガシーシステムと統合するときによく見られる
 • 供給者の契約が頻繁に変更される場合
 ◦ 腐敗防止層によってモデルの頻繁な変更から保護できる

  9. Separate Ways / 別々の道
 • 別々の道は全くコラボレーションしないパターン
 • チームが協力することを望まない、またはできない場合に発生する
 • 複数の境界づけられたコンテクストで機能を複製する方が費用対効果が高い場合

    がある
 ◦ 例えばロギングフレームワークは複数コンテクストで必要となるが、各コンテク ストで個別で実装したほうが統合の仕組みを考えるより低コストで済む
 • コンテクスト同士のモデルの違いが大きく、腐敗防止層での変換が難しい場合に 別々の道を進む方が費用対効果が高くなる

  10. Context Map / コンテクストマップ
 • 概要設計
 ◦ システムコンポーネントとコンポーネントが実装するモデルの概要を示す
 • コミュニケーションパターン


    ◦ どのチームが共同作業を行っているか、どのチームがあまり親密でない統合パターン を好むかなどがわかる
 • 組織の問題
 ◦ 特定の上流チームの下流顧客がすべて腐敗防止層に頼っている、別々の道の全て の実装が同じチームに集中している、などの組織的な問題がわかる
 コンテクストマップから以下のような貴重な戦略的洞察が得られる
  11. Context Map / コンテクストマップ
 • コンテクストマップの作成は困難な作業になる可能性があることに注意
 • システムの境界づけられたコンテクストが複数のサブドメインを含む場合、複数の統合パ ターンが作用する可能性がある
 •

    境界づけられたコンテクストが1つのサブドメインに制限されている場合でも、サブドメイン のモジュールが異なる統合戦略を必要とする、など複数の統合パターンが存在する可能 性がある

  12. Conclusion / 結論
 • パートナーシップ
 ◦ アドホックな方法での統合
 • 共有カーネル
 ◦

    重複モデルを共有することで統合
 • 順応者
 ◦ 顧客は供給者のモデルに準拠する
 • 腐敗防止層
 ◦ 顧客は供給者のモデルを自分のニーズにあったモデルに変換する

  13. Conclusion / 結論
 • オープンホストサービス
 ◦ 供給者は顧客のニーズに合わせて最適化された公開言語を実装する
 • 別々の道
 ◦

    特定の機能を複製する方がコラボレーションして統合するよりも費用がかから ない場合がある
 • コンテクストマップ
 ◦ 境界づけられたコンテクスト間の統合は、コンテクストマップにプロットできる
 ◦ システムの概要設計、コミュニケーションパターン、組織の問題に関する洞察 を提供する