Learning Domain-Driven Design輪読会#5

Transcript

1. Learning Domain-Driven Design

   輪読会 #5

   株式会社Showcase Gig 

   中島 清貴 (@ahyataro) 

   #lddd_rindoku

   Chapter 4. Integrating Bounded Contexts 

   

   View Slide

2. 本資料は書籍「Learning Domain-Driven
   Design」のChapter4を意訳・要約したもの
   です。

   資料に記載の内容は @ahyataro が解釈し
   た内容であり、原文の表現や内容と異な
   るものも含まれています

   注意

   

   View Slide

3. OverView

   Chapter 4. Integrating Bounded Contexts

   ● Cooperation / 協力

   ● Customer-Supplier / 顧客-供給者

   ● Separate Ways / 別々の道

   ● Context Map / コンテクストマップ

   ● Conclusion / 結論

   ● Exercises / エクササイズ

   

   View Slide

4. Integrating Bounded Contexts / 境界づけられたコンテクストの統合

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

   契約の必要性は、境界づけられたコンテクストのモデルと言語の違いから生じる。

   

   View Slide

5. Integrating Bounded Contexts / 境界づけられたコンテクストの統合

   この章では以下の3つの統合パターンについて説明する

   ● 協力

   ● 顧客-供給者

   ● 別々の道

   

   View Slide

6. 4-1.
   Cooperation
   / 協力
   

   View Slide

7. Cooperation / 協力

   ● 協力パターンは、十分に確立されたコミュニケーションを持つチームに
   よって形成される

   ● 一方のチームの成功が、もう一方のチームの成功に依存する

   ● パートナーシップと共有カーネルパターンがある

   

   View Slide

8. Partnership / パートナーシップ

   ● パートナーシップモデルでは、境界づけられたコンテクスト間の統合がアドホックな
   方法で調整される

   ● 一方のチームが行ったAPIの変更がもう一方に伝わり、協力して適応する

   

   View Slide

9. Partnership / パートナーシップ

   ● 統合の調整は双方向

   ● 各々のチームは各々のソリューションを選択できる

   ● 統合に問題が生じた場合は双方が協力して解決する

   ● 双方の仕事をブロックすることに関心を持たない

   ● パートナーシップモデルを成功させるには、確立されたコラボレーションプラクティ
   ス、高いレベルのコミットメント、チーム間の頻繁な同期が必要

   ● そのため地理的に分散したチームには向かない

   

   View Slide

10. Shared Kernel / 共有カーネル

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

    ● 全ての境界づけられたコンテクストの
    ニーズを満たすように設計する必要
    がある

    ● 一貫性があることも重要

    

    View Slide

11. Shared Kernel / 共有カーネル

    ● 共有モデルに加えられた変更は、全てのコンテクストに即座に影響する

    ● 変更の影響を最小限に抑えるには、共有するモデルを必要最低限にする

    ● コンテクスト境界を越えて渡されることを目的とした統合コントラクトとデータ構造の
    みで共有カーネルが構成されることが理想

    共有するスコープ

    

    View Slide

12. Shared Kernel / 共有カーネル

    ● 単一リポジトリ内で実装する

    ○ 複数のコンテクストで共通のソースファイルを参照する

    ● 共有カーネル用のライブラリを作る

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

    実装方法

    

    View Slide

13. Shared Kernel / 共有カーネル

    ● 重複コストと統合コストの違いはモデルの変動性によって異なる

    ● 頻繁に変更するほど統合コストは高くなる

    ● したがって共有カーネルは最も変化の激しいサブドメインであるコアサブドメインに適
    用される

    ● 共有カーネルを導入することは、単一チームが境界づけられたコンテクストを所有す
    るという原則に矛盾するため、慎重に検討が必要

    ○ 複数チームがひとつの共有カーネルの開発をすることになるので

    共有カーネルの使いどころ

    

    View Slide

14. Shared Kernel / 共有カーネル

    ● 地理的な制約や組織の政治のためにコラボレーションの問題があり、パートナーシップパ
    ターンができない場合

    ○ 共有カーネルのスコープを最小化することで、変更による影響範囲が制御され、変更
    ごとに統合テストを行うことで、統合時の問題を早期に検出できる

    ● レガシーシステムの段階的なモダナイゼーションをしたい場合

    ○ このようなシナリオでは、共有コードベースは境界づけられたコンテクストに徐々に分
    解されるため、実用的な中間ソリューションになる

    ● 同じチームが担当する境界づけられたコンテクストを統合する場合にも役に立つ

    ○ このような場合、境界づけられたコンテキストのアドホックな統合(パートナーシップ)に
    より、時間の経過と共に境界が「洗い流される」可能性がある

    共有カーネルが適している場面

    

    View Slide

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

    View Slide

16. Customer-Supplier / 顧客-供給者

    ● 供給者(上流)が顧客(下流)にサービスを提供するという関係性のパターン

    ● 「協力」の場合とは違い、両チームは独立して開発できる

    

    View Slide

17. Customer-Supplier / 顧客-供給者

    顧客-供給者パターンでは力関係が不均衡である場合がほとんどである。

    このような力関係の違いに対処するためのパターンが以下の3つである

    ● 順応者

    ● 腐敗防止層

    ● オープンホストサービス

    

    View Slide

18. Conformist / 順応者

    ● 下流チームが上流チームのモデルを受け入れる関係性を順応者と呼ぶ

    ● 上流チームは下流チームのニーズをサポートすることはなく、独自のモデルに従っ
    て定義された統合契約を提供するだけ

    ● このような力の不均衡は、組織の外部にあるサービスプロバイダーとの統合時や、
    組織内の政治によって引き起こされる

    

    View Slide

19. Anticorruption Layer / 腐敗防止層

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

    

    View Slide

20. Anticorruption Layer / 腐敗防止層

    腐敗防止層の使いどころ

    ● 下流のコンテクストにコアサブドメインが含まれる場合

    ○ コアサブドメインのモデルには特別な注意が必要であり、供給者のモデルに準
    拠するとモデリングが妨げられる可能性がある

    ● 上流のモデルが顧客にとって非効率的または不便である場合

    ○ レガシーシステムと統合するときによく見られる

    ● 供給者の契約が頻繁に変更される場合

    ○ 腐敗防止層によってモデルの頻繁な変更から保護できる

    

    View Slide

21. Open-Host Service / オープンホストサービス

    ● 実装モデルの変更から顧客を保護するために、上流の供給者は実装モデルをパブ
    リックインターフェースから切り離す

    ● 供給者のパブリックインターフェースはユビキタス言語に準拠せず、統合指向の言
    語で表現され、顧客にとって便利なプロトコルを公開する

    

    View Slide

22. Open-Host Service / オープンホストサービス

    ● 境界づけられたコンテクストの実装モデル
    と統合モデルを分離することで下流のコン
    テクストに影響を与えることなく実装を自
    由に進化させられる

    ● 公開言語を複数バージョン公開できるの
    で、顧客は新しいバージョンに徐々に移行
    できる

    

    View Slide

23. 4-3.
    Separate Ways
    / 別々の道
    

    View Slide

24. Separate Ways / 別々の道

    ● 別々の道は全くコラボレーションしないパターン

    ● チームが協力することを望まない、またはできない場合に発生する

    ● 複数の境界づけられたコンテクストで機能を複製する方が費用対効果が高い場合
    がある

    ○ 例えばロギングフレームワークは複数コンテクストで必要となるが、各コンテク
    ストで個別で実装したほうが統合の仕組みを考えるより低コストで済む

    ● コンテクスト同士のモデルの違いが大きく、腐敗防止層での変換が難しい場合に
    別々の道を進む方が費用対効果が高くなる

    

    View Slide

25. Separate Ways / 別々の道

    ● コアサブドメインを統合する場合は別々の道を避けるべき

    ● コアサブドメインの実装を複製すると、最も効果的で最適化された方法で実装する
    という戦略に反することになる

    

    View Slide

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

    View Slide

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

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

    

    View Slide

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

    ● 概要設計

    ○ システムコンポーネントとコンポーネントが実装するモデルの概要を示す

    ● コミュニケーションパターン

    ○ どのチームが共同作業を行っているか、どのチームがあまり親密でない統合パターン
    を好むかなどがわかる

    ● 組織の問題

    ○ 特定の上流チームの下流顧客がすべて腐敗防止層に頼っている、別々の道の全て
    の実装が同じチームに集中している、などの組織的な問題がわかる

    コンテクストマップから以下のような貴重な戦略的洞察が得られる
    

    View Slide

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

    ● コンテクストマップが最初からプロジェクトに導入され、境界づけられたコンテクス
    トの新規追加と更新が反映されることが理想

    ● コンテクストマップのメンテナンスは複数チームで共同で行うことが望ましい

    ● Context Mapper というツールでコンテクストマップをコード管理できる

    

    View Slide

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

    ● コンテクストマップの作成は困難な作業になる可能性があることに注意

    ● システムの境界づけられたコンテクストが複数のサブドメインを含む場合、複数の統合パ
    ターンが作用する可能性がある

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

    

    View Slide

31. 4-5.
    Conclusion
    / 結論
    

    View Slide

32. Conclusion / 結論

    ● パートナーシップ

    ○ アドホックな方法での統合

    ● 共有カーネル

    ○ 重複モデルを共有することで統合

    ● 順応者

    ○ 顧客は供給者のモデルに準拠する

    ● 腐敗防止層

    ○ 顧客は供給者のモデルを自分のニーズにあったモデルに変換する

    

    View Slide

33. Conclusion / 結論

    ● オープンホストサービス

    ○ 供給者は顧客のニーズに合わせて最適化された公開言語を実装する

    ● 別々の道

    ○ 特定の機能を複製する方がコラボレーションして統合するよりも費用がかから
    ない場合がある

    ● コンテクストマップ

    ○ 境界づけられたコンテクスト間の統合は、コンテクストマップにプロットできる

    ○ システムの概要設計、コミュニケーションパターン、組織の問題に関する洞察
    を提供する

    

    View Slide

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

    View Slide

35. Exercises / エクササイズ

    1. コアサブドメインに使用してはならない統合パターンはどれでしょう？

    a. 共有カーネル

    b. オープンホストサービス

    c. 腐敗防止層

    d. 別々の道

    

    View Slide

36. Exercises / エクササイズ

    1. コアサブドメインに使用してはならない統合パターンはどれでしょう？

    a. 共有カーネル

    b. オープンホストサービス

    c. 腐敗防止層

    d. 別々の道

    

    View Slide

37. Exercises / エクササイズ

    2. 腐敗防止層を実装する可能性が高い下流サブドメインはどれでしょう？

    a. コアサブドメイン

    b. サポーティングサブドメイン

    c. 汎用サブドメイン

    d. bとc

    

    View Slide

38. Exercises / エクササイズ

    2. 腐敗防止層を実装する可能性が高い下流サブドメインはどれでしょう？

    a. コアサブドメイン

    b. サポーティングサブドメイン

    c. 汎用サブドメイン

    d. bとc

    

    View Slide

39. Exercises / エクササイズ

    3. オープンホストサービスを実装する可能性が高い上流サブドメインはどれ　 で
    しょう？

    a. コアサブドメイン

    b. サポーティングサブドメイン

    c. 汎用サブドメイン

    d. bとc

    

    View Slide

40. Exercises / エクササイズ

    3. オープンホストサービスを実装する可能性が高い上流サブドメインはどれ　 で
    しょう？

    a. コアサブドメイン

    b. サポーティングサブドメイン

    c. 汎用サブドメイン

    d. bとc

    

    View Slide

41. Exercises / エクササイズ

    4. ある意味で境界づけられたコンテクストの所有権のルールに違反する統合 

    パターンはどれでしょう？

    a. パートナーシップ

    b. 共有カーネル

    c. 別々の道

    d. 統合パターンによって所有権のルー
    ルが破られることはない

    

    View Slide

42. Exercises / エクササイズ

    4. ある意味で境界づけられたコンテクストの所有権のルールに違反する統合 

    パターンはどれでしょう？

    a. パートナーシップ

    b. 共有カーネル

    c. 別々の道

    d. 統合パターンによって所有権のルー
    ルが破られることはない

    

    View Slide