Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Learning Domain-Driven Design輪読会#12

kyotak
September 22, 2022
110

Learning Domain-Driven Design輪読会#12

kyotak

September 22, 2022
Tweet

Transcript

  1. Learning Domain-Driven Design
 輪読会 #12
 株式会社Showcase Gig 
 中島 清貴

    (@ahyataro) 
 #lddd_rindoku
 Chapter 10. Design Heuristics 

  2. OverView
 Chapter 10. Design Heuristics
 • Heuristic / ヒューリスティック
 •

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

  3. Heauristic / ヒューリスティック
 • ヒューリスティックは、100%のケースで正しいことが保証されるような厳密な ルールではない
 • 経験則であり、完璧であることを保証するものではないが、当面の目標を達成 するには十分なものである
 •

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

  4. Bounded Context • 境界づけられたコンテクストには広い境界と狭い境界の両方がある
 • 境界づけられたコンテクストの最適なサイズは何だろうか?
 • 常に可能な限り最小のコンテクストのために努力すべきだろうか?
 • 著者の友人ニック・チューン曰く


    ◦ 「サービスの境界を定義するための有用で明確なヒューリスティックは数多く あるが、サイズは最も役に立たないものの1つである」
 • モデルを小さな境界づけられたコンテクストに最適化するよりも、モデルを包含す るサイズのコンテクストにしたほうがはるかに効果的である

  5. Bounded Context • 複数の境界づけられたコンテクストに影響を与 えるソフトウェアの変更は高コストであり、特に 影響を受ける境界づけられたコンテクストが異 なるチームによって実装されている場合、多く の調整が必要である 
 •

    単一のコンテクストにカプセル化されていない このような変更は、境界の設計が効果的でない ことを示す
 • コンテクスト境界のリファクタリングはコストのか かる作業であり、多くの場合効果のない境界は 放置されたままであり、技術的負債を蓄積する ことになる

  6. Bounded Context • コンテクストの境界を無効にする変更は、ビジネスドメインがあまり理解されていないか、ビジネス 要件が頻繁に変更される場合に発生する 
 • 第1章で学習したように、ボラティリティと不確実性の両方がコアサブドメインのプロパティであり、特 に実装の初期段階ではそうである
 ◦

    これらはコンテクストの境界を設計するためのヒューリスティックとして使用できる 
 • 広い境界、または複数のサブドメインを包含する境界は、含まれるサブドメインの境界またはモデ ルが間違っていても安全である
 • 論理境界のリファクタリングは物理境界のリファクタリングよりも低コスト 
 • したがって境界づけられたコンテクストを設計するときはより広い境界から始めるべき 
 • ドメイン知識を得るにつれて、必要に応じて小さく分解する 

  7. Business Logic Implementation Patterns
 • トランザクションスクリプトとアクティブレコードパターンはどちらも、単純なビジネス ロジックを持つサブドメインに適している
 • 2つのパターンの違いはデータ構造の複雑さである
 •

    トランザクションパターンは単純なデータ構造に、アクティブレコードパターンはデー タベースへの複雑なデータ構造のマッピングをカプセル化するのに役立つ

  8. Business Logic Implementation Patterns
 • ドメインモデルとイベントソースドメインモデルは、複雑なビジネスロジックを持つサ ブドメイン(コアサブドメイン)に適している
 • 以下のコアサブドメインはイベントソースドメインモデルが適している
 ◦

    金銭的取引を扱うコアサブドメイン
 ◦ 監査ログの提供が法律で義務付けられているコアサブドメイン
 ◦ システムの動作の詳細な分析を必要とするコアサブドメイン

  9. Business Logic Implementation Patterns
 適切なビジネスロジックの実装パターンを選択するための効果的なヒューリスティックは 以下の質問をすることである
 • サブドメインは、お金やその他の金銭的取引を追跡しているか?一貫性のある監査ログ を提供する必要があるか?ビジネスによってその動作の詳細な分析が必要か?
 ◦

    この場合イベントソースドメインモデルを使用する。該当しないなら...
 • サブドメインのビジネスロジックは複雑か?
 ◦ この場合ドメインモデルを実装する。該当しないなら...
 • サブドメインには複雑なデータ構造が含まれるか?
 ◦ その場合はアクティブレコードパターンを使用する。該当しないなら...
 • トランザクションスクリプトパターンを実装する

  10. Business Logic Implementation Patterns
 • 別のヒューリスティックを使用して、複雑なビジネスロジックと単純なビジネスロジッ クの違いを定義できる
 ◦ 複雑なビジネスロジックには、複雑なビジネスルール、不変条件、およびアル ゴリズムが含まれる


    ◦ 単純なビジネスロジックは主に入力の検証を中心に展開される
 • 複雑さを評価するためのもう一つのヒューリスティックは、ユビキタス言語自体の複 雑に関係する
 ◦ 主にCRUD操作を記述するのか?それともより複雑なビジネスプロセスとルー ルを記述するのか?

  11. Architectural Patterns
 • イベントソースドメインモデルにはCQRSが必要 
 ◦ そうしないとシステムはデータクエリオプションが非常に制限され、IDのみで単一のインスタンスを 取得することになる 
 ◦

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

  12. Tactical Design Decision Tree
 • サブドメインの種類を特定し、デシジョンツリーに従うことで設計上の重要の決定を下すための堅実 な出発点を得られる
 • とはいえこれらはヒューリスティックであり、厳しいルールではないことに注意 


    • デシジョンツリーは単純なツリーを使用し、ドメインモデル、イベントソースドメインモデル、CQRSな どの高度なパターンを絶対に必要な場合のみ使用するという著者の好みに基づいている 
 • すべてのサブドメインにイベントソースドメインモデルを使用することは、すべての人におすすめでき るかというとそんなことはない
 • 結局のところそれは特定のコンテクストに依存する 
 • デシジョンツリーは最初の指針として使用し、必要に応じて自分たちに合った形に変えていくべき 

  13. Conclusion • この章ではPart1とPart2をヒューリスティックベースの意思決定フレームワークで繋げた 
 • ビジネスドメインとそのサブドメインの知識を適用して技術的な意思決定を推進する方法を学習した 
 ◦ 安全な境界づけられたコンテクストの境界の選択 


    ◦ アプリケーションのビジネスロジックのモデル化 
 ◦ 各境界づけられたコンテクストの内部のコンポーネントの相互作用を調整するために必要な アーキテクチャパターンの決定
 ◦ ビジネスドメインに応じてさまざまなテストに優先順位の決定 
 • 設計上の決定を下すことは重要だが、時間の経過とともに決定の有効性を検証することはさらに重 要である
 • 次の章では、ソフトウェア設計のライフサイクルの次のフェーズである設計決定の進化について議論 を移す