Learning Domain-Driven Design輪読会#12

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

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

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

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

10-1. Heauristic / ヒューリステティック

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

10-2. Bounded Context / 境界づけられたコンテクスト

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

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

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

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

10-3. Business Logic Implementation Patterns / ビジネスロジックの実装パターン

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

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

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

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

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

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

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

10-4. Architectural Patterns / アーキテクチャパターン

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

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

Architectural Patterns 

10-5. Testing Strategy / テスト戦略

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

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

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

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

Testing Strategy 

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

Tactical Design Decision Tree 

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

10-7. Conclusion / 結論

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

10-8. Exercises / エクササイズ

Exercises

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

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

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

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

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

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

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

Learning Domain-Driven Design輪読会#12

Learning Domain-Driven Design輪読会#12

kyotak

More Decks by kyotak

Featured

Transcript