Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Learning Domain-Driven Design輪読会#5
Search
kyotak
June 02, 2022
1
290
Learning Domain-Driven Design輪読会#5
kyotak
June 02, 2022
Tweet
Share
More Decks by kyotak
See All by kyotak
株式会社Sunset Base
kyotak
0
1.3k
Learning Domain-Driven Design輪読会 #19
kyotak
0
58
Learning Domain-Driven Design輪読会#16
kyotak
0
78
Learning Domain-Driven Design輪読会#12
kyotak
2
130
Learning Domain-Driven Design輪読会#7
kyotak
0
140
Learning Domain-Driven Design輪読会#2
kyotak
1
570
新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介
kyotak
3
3.6k
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
334
57k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
How STYLIGHT went responsive
nonsquared
95
5.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
8
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
What's in a price? How to price your products and services
michaelherold
243
12k
Gamification - CAS2011
davidbonilla
80
5.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
KATA
mclloyd
29
14k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
Code Review Best Practice
trishagee
64
17k
Fireside Chat
paigeccino
34
3.1k
Transcript
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 / エクササイズ 1. コアサブドメインに使用してはならない統合パターンはどれでしょう? a. 共有カーネル b. オープンホストサービス c.
腐敗防止層 d. 別々の道
Exercises / エクササイズ 2. 腐敗防止層を実装する可能性が高い下流サブドメインはどれでしょう? a. コアサブドメイン b. サポーティングサブドメイン c.
汎用サブドメイン d. bとc
Exercises / エクササイズ 2. 腐敗防止層を実装する可能性が高い下流サブドメインはどれでしょう? a. コアサブドメイン b. サポーティングサブドメイン c.
汎用サブドメイン d. bとc
Exercises / エクササイズ 3. オープンホストサービスを実装する可能性が高い上流サブドメインはどれ で しょう? a. コアサブドメイン b.
サポーティングサブドメイン c. 汎用サブドメイン d. bとc
Exercises / エクササイズ 3. オープンホストサービスを実装する可能性が高い上流サブドメインはどれ で しょう? a. コアサブドメイン b.
サポーティングサブドメイン c. 汎用サブドメイン d. bとc
Exercises / エクササイズ 4. ある意味で境界づけられたコンテクストの所有権のルールに違反する統合 パターンはどれでしょう? a. パートナーシップ b.
共有カーネル c. 別々の道 d. 統合パターンによって所有権のルー ルが破られることはない
Exercises / エクササイズ 4. ある意味で境界づけられたコンテクストの所有権のルールに違反する統合 パターンはどれでしょう? a. パートナーシップ b.
共有カーネル c. 別々の道 d. 統合パターンによって所有権のルー ルが破られることはない