Learning DDD輪読会#4 / Learning DDD Book Club #4

株式会社Showcase Gig主催の輪読会の資料です。
https://showcase-gig.connpass.com/event/246665/

Transcript

1. 『Learning Domain-Driven Design』 📚 輪読会 #4🐒 Chapter3. Managing Domain Complexity #lddd_rindoku 2022/05/19 株式会社Showcase Gig @suzushin54
2. Disclaimer ❏ 本スライドは、以下の書籍を要約・引⽤の範囲内で紹介します。 ❏ Vladik Khononov『Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy』Oreilly & Associates Inc (2021/11/2) ❏ https://www.oreilly.com/library/view/learning-domain-driven- design/9781098100124/ ❏ 原⽂、正確な翻訳⽂は著作権法および翻訳権に抵触するため掲載しません。 2
3. Overview Managing Domain Complexity / ドメイン複雑性の管理 § Inconsistent Models / ⼀貫性のないモデルたち § What Is a Bounded Context? / 境界づけられたコンテクストとは? § Bounded Contexts Versus Subdomains / 境界づけられたコンテクストとサブドメ インの⽐較 § Boundaries / 境界 § Bounded Contexts in Real Life / 実⽣活における境界づけられたコンテクスト § Conclusion / 結論 § Exercise / エクササイズ 3
4. Chapter3. Managing Domain Complexity - ドメイン複雑性の管理 ❏ プロジェクト成功のために、すべてのステークホルダーがコミュニケーションに使え るユビキタス⾔語を作ることが重要 ❏ ユビキタス⾔語には、 ❏ ドメインエキスパートのメンタルモデル*1 が反映されている必要がある ❏ 明確で⼀貫性が必要。曖昧さ、暗黙の前提などは排除する ❏ 組織規模によっては、ドメインエキスパートのメンタルモデルに⼀貫性がない ❏ 同じビジネスドメインでも、ドメインエキスパートによって異なるモデルを使⽤する ことがある 4 *1 ⼈間が無⾃覚のうちに持っている、思い込みや価値観
5. Inconsistent Models / ⼀貫性のないモデルたち 5
6. Inconsistent Models ❏ Chapter2 に出てきたテレマーケティング会社の例 ❏ オンライン広告を通じてリードを獲得、営業部⾨が⾒込み客に勧誘する 6 ❏ マーケティング部⾨ ❏ リードとは、誰かがプロダクトの1つに興味を持っているという通知を意味する ❏ ⾒込み客の連絡先を受け取ること(event)をリードと⾒なす ❏ 営業部⾨ ❏ もっと複雑な存在(entity)。イベントではなく、営業プロセスのライフサイクル全体を表す
7. Inconsistent Models ユビキタス⾔語には⼀貫性が必要で、意味は1つでなければならない。 また、ドメインエキスパートのメンタルモデルが反映されていなければならない。 ❏ この会社の場合、営業とマーケのドメインエキスパートの間で 「Lead」のメンタルモデルに⼀貫性がない ❏ 解決案1. 全ての問題に使えるモデルを設計 ❏ 👎 巨⼤な E-R図を⽣み出すことになる。結局は何の効果もない ❏ 解決案2. ⽤語の前に⽂脈の定義を追加する ❏ e.g. “マーケティングリード”、“セールスリード” ❏ 👎 認知的な負荷がかかる。ユビキタス⾔語と⼀致しなくなる ❏ 👎 会話には⽂脈があるので、接頭辞を使う⼈はいない 7 このようなシナリオに対処するには DDD の設計パターンである境界づけられたコンテクストを使う
8. What Is a Bounded Context? / 境界づけられたコンテクストとは? 8
9. What Is a Bounded Context? ❏ DDDにおける解決策は些細(trivial)なこと ❏ ユビキタス⾔語を複数の⼩さな⾔語に分割 ❏ それぞれを適⽤可能な明⽰的なコンテクスト（境界づけられたコンテクスト）に割り当てる 9
10. What Is a Bounded Context? Model Boundaries ❏ モデルは現実世界のコピーではなく複雑なシステムを理解するための構成要素 ❏ モデルは境界なしに存在することはできない ❏ 前章の様々な地図の例では航空写真、地下鉄など、固有のコンテクストがあった ❏ 地下鉄の地図が航海で役⽴たないように、異なるコンテクストでは役⽴たないこともある ❏ 境界づけられたコンテクストはユビキタス⾔語の⼀貫性の境界 ❏ ユビキタス⾔語とそれが表現するモデルの適⽤可能性を定義する ❏ 様々な問題領域に対して、異なるモデルを定義できるようになる ❏ ⽤語、原理、ビジネスルールは、その境界内でのみ⼀貫性が保たれる 10
11. What Is a Bounded Context? Ubiquitous Language Refined 境界づけられたコンテクストによって、ユビキタス⾔語の定義が完成する 11 ユビキタス⾔語とは普遍的なものではない 組織内で「ユビキタス」に使われ、適⽤されるという意味ではない。 その境界のコンテクストにおいてのみ、ユビキタスである。
12. What Is a Bounded Context? 12 Scope of a Bounded Context ❏ オンライン広告会社の例では、ドメインに固有の境界があることがわかる ❏ 異なるドメインエキスパートのメンタルモデルがコンフリクトしている ❏ ビジネスドメインをモデル化するには、モデルを分割して適⽤可能なコンテクストを定義する ❏ 図のように、さらに⼩さく分割することもできる
13. What Is a Bounded Context? 13 Scope of a Bounded Context ユビキタス⾔語のスコープ、つまり境界づけられたコンテクストの定義は 戦略的設計における意思決定である ❏ サイズは⼤きいことも⼩さいこともあるが、それよりモデルが有⽤であるかが⼤事 ❏ 境界づけられたコンテクストのサイズは、問題領域によって異なる まとまった機能を複数の境界づけられたコンテクストに分割しない 各コンテクストを独⾃に進化させる能⼒を妨げてしまう サブドメインを⾒つけて⾮効率的な分解を避ける 同じデータで動作する⾸尾⼀貫したUseCaseセットを特定する
14. Bounded Contexts Versus Subdomains / 境界づけられたコンテクストとサブドメインの⽐較 14
15. Bounded Contexts Versus Subdomains Subdomains ❏ 企業の事業戦略を理解するためには、事業ドメインを分析する必要がある ❏ サブドメインはユースケースの集合に似ていて、ビジネスドメインとシステムの要件 によって定義される ❏ エンジニアは要件を定義しないが、ビジネスドメインを分析することでサブドメイン を発⾒(特定)する Bounded Contexts ❏ 設計されたもの。モデルの境界を選択するのは、戦略的設計における意思決定 ❏ ビジネスドメインを⼩さく管理しやすい問題領域に分割する⽅法を決められる 15
16. Bounded Contexts Versus Subdomains The Interplay Between Subdomains and Bounded Contexts ❏ ⾮現実的であるが、理論的には1つのモデルでドメイン全体をカバーすることはできる ❏ ⼩さなシステムには有効かもしれない🤔 16
17. Bounded Contexts Versus Subdomains The Interplay Between Subdomains and Bounded Contexts ❏ ⽭盾するモデルが発⽣したら、ドメインエキスパートのメンタルモデルに 従って分割することができる 17
18. Bounded Contexts Versus Subdomains The Interplay Between Subdomains and Bounded Contexts ❏ それでもまだモデルが⼤きく、保守が難しい場合 ❏ 各サブドメインに対して境界づけられたコンテクストを持ち、さらに分割できる 18
19. Bounded Contexts Versus Subdomains The Interplay Between Subdomains and Bounded Contexts ❏ どのように分割するにしても、これは設計上の判断 ❏ その境界をソリューションの⼀部として設計する 19 ⼀対⼀の関係が必ず良いとは限らない 境界づけられたコンテクストとサブドメインが⼀対⼀の関係にあることが、 あるシナリオでは合理的でも、別のシナリオでは異なる分割⽅法が適していることも。 ⼀対⼀に限定して設計すると柔軟性が失われ、複数の境界づけられたコンテクスト において単⼀モデルの使⽤を余儀なくされる。
20. Boundaries / 境界 20
21. “Architectural design is system design. System design is contextual design ̶ it is inherently about boundaries (whatʼs in, whatʼs out, what spans, what moves between), and about tradeoffs. It reshapes what is outside, just as it shapes what is inside. ” [Software Architects: Do We Need 'em?] by Ruth Malan https://www.bredemeyer.com/who.htm 21 “アーキテクチャ設計はシステム設計である。システム設計は⽂脈の設計である。本質的には、境界 （何が⼊っているか、何が出ているか、何が広がっているか、何がその間を移動するか）とトレードオフである。 それは内側にあるものを形作るのと同じように、外側にあるものを再形成する。” Boundaries Ruth Malan が書いているとおり、アーキテクチャ設計は本質的には境界線に関するもの
22. Boundaries 22 Physical Boundaries 境界づけられたコンテクストはモデルの境界としてだけではなく、それを実装したシステム の物理的な境界としても機能する 境界づけられたコンテクストは独⽴したサービスやプロジェクトとして実装する ニーズに最も適した技術スタックで実装できる ❏ ひとつの境界づけられたコンテクストに複数サブドメインが含まれることもある ❏ 境界づけられたコンテクスト︓物理的な境界 ❏ サブドメイン︓論理的な境界 ❏ 名前空間、モジュール、パッケージ …etc ⾔語によって呼び⽅が異なる
23. Boundaries 23 Ownership Boundaries ❏ 各チームはモデルとシステムを統合するためのプロトコルを明⽰的に定義する ❏ ひとつのチームだけが境界づけられたコンテクストを実装、進化、維持する ❏ 掛け持ちはOK
24. Bounded Contexts in Real Life / 実⽣活における境界づけられたコンテクスト 24
25. Bounded Contexts in Real Life 25 ❏ 現実の⽣活の中で、境界づけられたコンテクストはどこにあるのか︖ ❏ ビジネスドメインやサブドメインほど明らかではないが、確かにそれは存在する ❏ ドメインエキスパートがビジネスエンティティやプロセスについて、どう考えている かを意識すれば良い👌 ❏ 最後に、異なるコンテクストで異なるモデルを使⽤する概念が⼀般的である例を⽰す
26. Bounded Contexts in Real Life Semantic Domains DDD の境界づけられたコンテクストは、意味領域の語彙的な概念に基づくといえる 26 意味領域とは その⽂脈の中で⼀連の意味を共有する特定の場所、あるいはその意味を保持する⾔語のこと 「モニタ」や「ポート」といった⾔葉は、ソフトウェア⼯学とハードウェア⼯学の意味領域で 異なる意味を持つ ❏ 植物学的には トマトはフルーツ 🍅
27. Bounded Contexts in Real Life Science ❏ “科学者は⼀般的に 100% 正しい理論などないということに同意している” ❏ 科学的な理論は常に正しいわけではなく、⽂脈によって有⽤な場合があるということ 27 以下の2つのモデルは⽭盾しているようで、適切な⽂脈においては役に⽴つ A. ニュートンの運動の法則 ˓ 空間と時間は絶対的なもの B. アインシュタインの相対性理論 ˓ 空間と時間は絶対的なものではなく、観測者によって異なる
28. Bounded Contexts in Real Life Buying a Refrigerator 何に⾒えますか︖段ボール︖ いいえ、これは冷蔵庫の模型です 28
29. Bounded Contexts in Real Life Buying a Refrigerator キッチンへの⼊⼝のサイズが標準的ではないため、冷蔵庫のサイズをチェックした 29
30. Bounded Contexts in Real Life Buying a Refrigerator 今回のモデルは冷蔵庫には全く似ていないが、冷蔵庫がキッチンに⼊るかどうか、 というサブドメインにおいては⾮常に役⽴った ❏ 冷蔵庫の 3D モデルを作るのは楽しいだろうが、効率が悪い ❏ ダンボールがフィットするなら、3D モデルもフィットするだろう ❏ 「LiDARスキャナとARアプリを使えばよいのでは」という意⾒もあった 30 シンプルなモデルで問題解決できるなら複雑な万能モデルは必要ない ソフトウェア⼯学の⽤語で⾔えば Overengineering である
31. Conclusion / 結論 31
32. Conclusion 32 ˒ ドメインエキスパートのメンタルモデルによっては、ユビキタス⾔語を複数の境界づ けられたコンテクストに分割する必要がある ˒ ユビキタス⾔語は、その範囲内で⼀貫した意味を持たなければならない ˓ 境界づけられたコンテクストをまたぐと、異なる意味を持つことがある ˒ サブドメインが発⾒されると、境界づけられたコンテクストが設計される。これは戦 略的設計における意思決定である ˒ 境界づけられたコンテクストと、そのユビキタス⾔語はひとつのチームが担当する ˒ 境界づけられたコンテクストは、システムを物理的なコンポーネントに分割する ˓ これによりライフサイクルも他から切り離される ˒ 境界づけられたコンテクストは、独⽴して進化することができる ˒ 境界づけられたコンテクストは、システムのために⼀緒に動作する必要がある
33. Exercise / エクササイズ 33
34. Exercise / エクササイズ 34 1. サブドメインと境界づけられたコンテクストの違いは︖ A. サブドメインは設計されるが、境界づけられたコンテクストは発⾒される B. サブドメインは発⾒されるが、境界づけられたコンテクストは設計される C. サブドメインと境界づけられたコンテクストは本質的に同じ D. 上記いずれも当てはまらない
35. Exercise / エクササイズ 35 1. サブドメインと境界づけられたコンテクストの違いは︖ A. サブドメインは設計されるが、境界づけられたコンテクストは発⾒される B. サブドメインは発⾒されるが、境界づけられたコンテクストは設計される C. サブドメインと境界づけられたコンテクストは本質的に同じ D. 上記いずれも当てはまらない
36. Exercise / エクササイズ 36 2. 境界づけられたコンテクストは、以下の境界である A. A model B. A lifecycle C. Ownership D. 上記すべて
37. Exercise / エクササイズ 37 2. 境界づけられたコンテクストは、以下の境界である A. A model B. A lifecycle C. Ownership D. 上記すべて
38. Exercise / エクササイズ 38 3. 境界づけられたコンテクストのサイズについて正しいのは︖ A. ⼩さいほどシステムの柔軟性は⾼くなる B. 常にサブドメインの境界と⼀致させるべき C. 広ければ広いほどよい D. 場合による
39. Exercise / エクササイズ 39 3. 境界づけられたコンテクストのサイズについて正しいのは︖ A. ⼩さいほどシステムの柔軟性は⾼くなる B. 常にサブドメインの境界と⼀致させるべき C. 広ければ広いほどよい D. 場合による
40. Exercise / エクササイズ 40 4. 境界づけられたコンテクストのチームオーナーシップについて正しいのは︖ A. 複数のチームが同じ境界づけられたコンテクストで作業する B. 1つのチームが複数の境界づけられたコンテクストで作業できる C. 1つの境界づけられたコンテクストを所有できるのは1チームだけである D. B と C が正しい
41. Exercise / エクササイズ 41 4. 境界づけられたコンテクストのチームオーナーシップについて正しいのは︖ A. 複数のチームが同じ境界づけられたコンテクストで作業する B. 1つのチームが複数の境界づけられたコンテクストで作業できる C. 1つの境界づけられたコンテクストを所有できるのは1チームだけである D. B と C が正しい
42. Exercise / エクササイズ 42 5. WolfDesk社の例を⾒直して、サポートチケットの異なるモデルを 必要とするシステムの機能性を識別してみましょう 6. 他に、現実の境界づけられたコンテクストの例を探してみましょう