Learning Domain-Driven Design輪読会#12

Transcript

1. Learning Domain-Driven Design
 輪読会 #12
 株式会社Showcase Gig 
 中島 清貴 (@ahyataro) 
 #lddd_rindoku
 Chapter 10. Design Heuristics 

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

3. OverView
 Chapter 10. Design Heuristics
 • Heuristic / ヒューリスティック
 • Bounded Contexts / 境界づけられたコンテクスト
 • Business Logic Implementation Patterns / ビジネスロジックの実装パターン
 • Architectural Patterns / アーキテクチャパターン
 • Testing Strategy / テスト戦略
 • Tactical Design Decision Tree / 戦術的設計デシジョンツリー 
 • Conclusion / 結論
 • Exercises / エクササイズ

4. Design Heuristics
 Part1ではビジネスドメインを分析し、戦略的な設計上の意思決定を行うためのド メイン駆動設計のツールについて学習した。
 Part2では戦術的設計パターンについて検討した。
 この章では、Part1とPart2の橋渡しをする。
 分析ツールを使ってさまざまなソフトウェア設計の決定、つまり(ビジネス)ドメイン 駆動(ソフトウェア)設計を推進するためのヒューリスティックを学習する。
 

5. 10-1. Heauristic / ヒューリステティック
6. Heauristic / ヒューリスティック
 • ヒューリスティックは、100%のケースで正しいことが保証されるような厳密な ルールではない
 • 経験則であり、完璧であることを保証するものではないが、当面の目標を達成 するには十分なものである
 • 言い換えれば、ヒューリスティックを使用することは、多くの手がかりに内在す るノイズを無視し、代わりに最も重要な手がかりに反映される「沼地の力」に焦 点を当てる効果的な問題解決アプローチである
 • この章で紹介するヒューリスティックは、さまざまなビジネスドメインの本質的な 特性と、さまざまな設計上の決定によって対処される問題の本質に焦点を当て る

7. 10-2. Bounded Context / 境界づけられたコンテクスト
8. Bounded Context • 境界づけられたコンテクストには広い境界と狭い境界の両方がある
 • 境界づけられたコンテクストの最適なサイズは何だろうか？
 • 常に可能な限り最小のコンテクストのために努力すべきだろうか？
 • 著者の友人ニック・チューン曰く
 ◦ 「サービスの境界を定義するための有用で明確なヒューリスティックは数多く あるが、サイズは最も役に立たないものの1つである」
 • モデルを小さな境界づけられたコンテクストに最適化するよりも、モデルを包含す るサイズのコンテクストにしたほうがはるかに効果的である

9. Bounded Context • 複数の境界づけられたコンテクストに影響を与 えるソフトウェアの変更は高コストであり、特に 影響を受ける境界づけられたコンテクストが異 なるチームによって実装されている場合、多く の調整が必要である 
 • 単一のコンテクストにカプセル化されていない このような変更は、境界の設計が効果的でない ことを示す
 • コンテクスト境界のリファクタリングはコストのか かる作業であり、多くの場合効果のない境界は 放置されたままであり、技術的負債を蓄積する ことになる

10. Bounded Context • コンテクストの境界を無効にする変更は、ビジネスドメインがあまり理解されていないか、ビジネス 要件が頻繁に変更される場合に発生する 
 • 第１章で学習したように、ボラティリティと不確実性の両方がコアサブドメインのプロパティであり、特 に実装の初期段階ではそうである
 ◦ これらはコンテクストの境界を設計するためのヒューリスティックとして使用できる 
 • 広い境界、または複数のサブドメインを包含する境界は、含まれるサブドメインの境界またはモデ ルが間違っていても安全である
 • 論理境界のリファクタリングは物理境界のリファクタリングよりも低コスト 
 • したがって境界づけられたコンテクストを設計するときはより広い境界から始めるべき 
 • ドメイン知識を得るにつれて、必要に応じて小さく分解する 

11. Bounded Context • このヒューリスティックは、汎用サブドメインと サポーティングサブドメインはボラティリティが 少ないため、主にコアサブドメインに適用され る
 • コアサブドメインを含む境界づけられたコンテ クストを作成する場合、コアサブドメインが最 も頻繁に対話する他のサブドメインを含めるこ とで予期しない変更から身を守ることができる (右図)

12. 10-3. Business Logic Implementation Patterns / ビジネスロジックの実装パターン
13. Business Logic Implementation Patterns
 ビジネスロジックについて詳しく説明した第５章から第７章では、ビジネスロジックをモデ ル化する以下の４つの異なる方法を学習した
 • トランザクションスクリプト
 • アクティブレコード
 • ドメインモデル
 • イベントソース

14. Business Logic Implementation Patterns
 • トランザクションスクリプトとアクティブレコードパターンはどちらも、単純なビジネス ロジックを持つサブドメインに適している
 • ２つのパターンの違いはデータ構造の複雑さである
 • トランザクションパターンは単純なデータ構造に、アクティブレコードパターンはデー タベースへの複雑なデータ構造のマッピングをカプセル化するのに役立つ

15. Business Logic Implementation Patterns
 • ドメインモデルとイベントソースドメインモデルは、複雑なビジネスロジックを持つサ ブドメイン(コアサブドメイン)に適している
 • 以下のコアサブドメインはイベントソースドメインモデルが適している
 ◦ 金銭的取引を扱うコアサブドメイン
 ◦ 監査ログの提供が法律で義務付けられているコアサブドメイン
 ◦ システムの動作の詳細な分析を必要とするコアサブドメイン

16. Business Logic Implementation Patterns
 適切なビジネスロジックの実装パターンを選択するための効果的なヒューリスティックは 以下の質問をすることである
 • サブドメインは、お金やその他の金銭的取引を追跡しているか？一貫性のある監査ログ を提供する必要があるか？ビジネスによってその動作の詳細な分析が必要か？
 ◦ この場合イベントソースドメインモデルを使用する。該当しないなら...
 • サブドメインのビジネスロジックは複雑か？
 ◦ この場合ドメインモデルを実装する。該当しないなら...
 • サブドメインには複雑なデータ構造が含まれるか？
 ◦ その場合はアクティブレコードパターンを使用する。該当しないなら...
 • トランザクションスクリプトパターンを実装する

17. Business Logic Implementation Patterns
 サブドメインの複雑さとそのタイプの間には強い関係があるため、ドメイン駆動デシジョン ツリーを使用してヒューリスティックを視覚化できる

18. Business Logic Implementation Patterns
 • 別のヒューリスティックを使用して、複雑なビジネスロジックと単純なビジネスロジッ クの違いを定義できる
 ◦ 複雑なビジネスロジックには、複雑なビジネスルール、不変条件、およびアル ゴリズムが含まれる
 ◦ 単純なビジネスロジックは主に入力の検証を中心に展開される
 • 複雑さを評価するためのもう一つのヒューリスティックは、ユビキタス言語自体の複 雑に関係する
 ◦ 主にCRUD操作を記述するのか？それともより複雑なビジネスプロセスとルー ルを記述するのか？

19. Business Logic Implementation Patterns
 • ビジネスロジックとそのデータ構造の複雑さに従ってビジネスロジックの実装パター ンを決定することは、サブドメインの種類に関する仮定を検証する方法である
 • 「コアサブドメインとみなすが最良のパターンはアクティブレコードまたはトランザク ションスクリプトである場合」または「サポーティングサブドメインにドメインモデルや イベントソースドメインモデルが必要であると思われる場合」
 • こういった場合、サブドメインとビジネスドメイン全般に関する仮定を再検討する絶 好の機会である

20. 10-4. Architectural Patterns / アーキテクチャパターン
21. Architectural Patterns
 • 第８章ではレイヤードアーキテクチャ、ポート&アダプター、CQRSの３つのパターン について学習した
 • 意図したビジネスロジックの実装パターンを把握することでアーキテクチャパターン の選択が簡単になる

22. Architectural Patterns
 • イベントソースドメインモデルにはCQRSが必要 
 ◦ そうしないとシステムはデータクエリオプションが非常に制限され、IDのみで単一のインスタンスを 取得することになる 
 ◦ ただしCQRSはイベントソースドメインモデルだけでなく、サブドメインが複数の永続モデルでデータ を表現する必要がある場合、他のパターンでも有効 
 • ドメインモデルにはポート&アダプターのアーキテクチャが必要 
 ◦ レイヤードアーキテクチャでは、集約および値オブジェクトに永続化の知識を意識させないといけ なくなる
 • アクティブレコードパターンにはレイヤードアーキテクチャにアプリケーション層(サービス層)を追加するこ とが最適
 ◦ アクティブレコードを制御するロジックのために必要 
 • トランザクションスクリプトパターンは３つのレイヤーのみで構成される最小限のレイヤードアーキテク チャで実装する 

23. Architectural Patterns

24. 10-5. Testing Strategy / テスト戦略
25. Testing Strategy
 • ビジネスロジックの実装パターンとアーキテクチャパターンの両方の知識は、コードベースのテスト 戦略を選択するためのヒューリスティックとして使用できる。 
 • テスト戦略には以下の３つがある。 
 • これらのテスト戦略の違いは、ユニット、統合、エンドツーエンドの様々なタイプのテストに重点が置 かれていること 

26. Testing Strategy
 • 従来のテストピラミッドでは、ユニットテストに重点を置 いており、統合テストはそれよりも少なく、エンドツーエ ンドはさらに少ない。
 • ドメインモデル、イベントソースドメインモデルパターン は、テストピラミッドで対処することが最適である 
 Testing Pyramid

27. Testing Strategy
 • テストダイヤモンドは統合テストに最も焦点を当ててい る
 • アクティブレコードパターンを使用すると、システムのビ ジネスロジックは定義上サービス層とビジネスロジック 層の両方に分散される
 • したがって２つのレイヤーを統合することに焦点を当て るにはテストダイヤモンドが最適
 Testing Diamond

28. Testing Strategy
 • 逆テストピラミッドはエンドツーエンドテストに最も注意を 払っている
 • このようなアプローチはトランザクションスクリプトパター ンが適している
 • ビジネスロジックは単純でレイヤー数が最小限に抑えら れているため、システムのエンドツーエンドフローを検 証することがより効果的である
 Reversed Testing Pyramid

29. Testing Strategy

30. 10-6. Tactical Design Decision Tree / 戦術的設計デシジョンツリー
31. Tactical Design Decision Tree

32. Tactical Design Decision Tree
 • サブドメインの種類を特定し、デシジョンツリーに従うことで設計上の重要の決定を下すための堅実 な出発点を得られる
 • とはいえこれらはヒューリスティックであり、厳しいルールではないことに注意 
 • デシジョンツリーは単純なツリーを使用し、ドメインモデル、イベントソースドメインモデル、CQRSな どの高度なパターンを絶対に必要な場合のみ使用するという著者の好みに基づいている 
 • すべてのサブドメインにイベントソースドメインモデルを使用することは、すべての人におすすめでき るかというとそんなことはない
 • 結局のところそれは特定のコンテクストに依存する 
 • デシジョンツリーは最初の指針として使用し、必要に応じて自分たちに合った形に変えていくべき 

33. 10-7. Conclusion / 結論
34. Conclusion • この章ではPart1とPart2をヒューリスティックベースの意思決定フレームワークで繋げた 
 • ビジネスドメインとそのサブドメインの知識を適用して技術的な意思決定を推進する方法を学習した 
 ◦ 安全な境界づけられたコンテクストの境界の選択 
 ◦ アプリケーションのビジネスロジックのモデル化 
 ◦ 各境界づけられたコンテクストの内部のコンポーネントの相互作用を調整するために必要な アーキテクチャパターンの決定
 ◦ ビジネスドメインに応じてさまざまなテストに優先順位の決定 
 • 設計上の決定を下すことは重要だが、時間の経過とともに決定の有効性を検証することはさらに重 要である
 • 次の章では、ソフトウェア設計のライフサイクルの次のフェーズである設計決定の進化について議論 を移す

35. 10-8. Exercises / エクササイズ
36. Exercises
37. Exercises 1. WolfDeskのチケットライフサイクル管理システムを実装しているとします。これ はコアサブドメインであり、アルゴリズムを時間の経過とともにさらに最適化で きるように、その動作の詳細な分析が必要である。ビジネスロジックとコンポー ネントのアーキテクチャを実装する最初の戦略はなんでしょうか？テスト戦略は なんでしょうか？

38. Tactical Design Decision Tree

39. Exercises 1. WolfDeskのチケットライフサイクル管理システムを実装しているとします。これ はコアサブドメインであり、アルゴリズムを時間の経過とともにさらに最適化で きるように、その動作の詳細な分析が必要である。ビジネスロジックとコンポー ネントのアーキテクチャを実装する最初の戦略はなんでしょうか？テスト戦略は なんでしょうか？
 A) イベントソースドメインモデル、CQRSアーキテクチャ、ユニットテストに焦点を当 てたテスト戦略(テストピラミッド)

40. Exercises 2. WolfDeskのサポートエージェントのシフト管理モジュールの設計上の
 　 決定事項はなんでしょうか？

41. Tactical Design Decision Tree

42. Exercises 2. WolfDeskのサポートエージェントのシフト管理モジュールの設計上の
 　 決定事項はなんでしょうか？
 A) シフトはレイヤードアーキテクチャパターンで作業するアクティブレコードとして モデル化できる。テスト戦略では統合テストに焦点を当てる必要がある(テスト ダイヤモンド)

43. Exercises 3. エージェントのシフトを管理するプロセスを容易にするために、さまざま
 な祝日の外部プロバイダーを使用する。このプロセスは定期的に外部プロ
 バイダーを呼び出し、今後の祝日の日付と名前を取得することによって
 機能する。統合を実装するためにどのようなビジネスロジックとアーキテ
 クチャパターンを使用するか？どのようにテストするか？

44. Tactical Design Decision Tree

45. Exercises 3. エージェントのシフトを管理するプロセスを容易にするために、さまざま
 な祝日の外部プロバイダーを使用する。このプロセスは定期的に外部プロ
 バイダーを呼び出し、今後の祝日の日付と名前を取得することによって
 機能する。統合を実装するためにどのようなビジネスロジックとアーキテ
 クチャパターンを使用するか？どのようにテストするか？
 A) ビジネスロジックはレイヤードアーキテクチャで編成されたトランザクションスクリ プトとして実装される。テスト観点ではエンドツーエンドのテストに集中し、完全な 統合フローを検証するべき(逆テストピラミッド)

46. Exercises 4. あなたの経験に基づいてソフトウェア開発プロセスの他のどのような
 　 側面をヒューリスティックベースのデシジョンツリーに含めることが
 できますか？