Learning Domain-Driven Design輪読会#7

Learning Domain-Driven Design  輪読会 #7  株式会社Showcase Gig   中島清貴
(@ahyataro)   #lddd_rindoku  Chapter 6. Tackling Complex Business Logic  

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

OverView  Chapter 6. Tackling Complex Business Logic  • History /
歴史  • Domain Model / ドメインモデル  • Conclusion / 結論  • Exercises / エクササイズ 

Tackling Complex Business Logic  前の章では比較的単純なビジネスロジックに対処する2つのパターン(トランザクションスクリプトとアクティブレコード)について説明した。  この章では複雑なビジネスロジック向けのドメインモデルパターンについて説明する。 

6-1. History / 歴史

History / 歴史  『Patterns of Enterprise Application Architecture』   著:
Martin Fowler   ドメインモデルパターンが最初に紹介された著書。Fowlerはこのパターンに関して「Eric Evansは現在、ドメインモデルの構築に関する本を書いている」と言って締めくくった  

History / 歴史  『Domain Driven Design:   Tackling Complexity in
the Heart of Software』   著: Eric Evans   コードをビジネスドメインの基礎となるモデル(集約、値オブジェクト、リポジトリなど)に厳密に関連づけることを目的とした一連のパターンを提示している。  

History / 歴史  • Evansが導入したパターンは戦術的ドメイン駆動設計と呼ばれることがよくある  • ビジネスロジックを実装するためにこれらのパターンを必ず使わなければならないという考え方をなくすために、LDDD本の著者はFowlerの元の用語を使うことを好んでいる  •
パターンはドメインモデルであり、集約や値オブジェクトは構成要素であると考えている 

6-2. Domain Model / ドメインモデル

Domain Model / ドメインモデル  • ドメインモデルパターンは複雑なビジネスロジックに対処することを目的としている  • 次のスライドに、この章で例として説明されているヘルプデスクサービスの要件を列挙する(WolfDesk?) 

• 顧客がサポートチケットを開く  • 顧客とサポートエージェントの両方がメッセージを追加し、全てのやりとりがサポートチケットによって追跡される  • 各チケットには低、中、高、緊急の優先度がある   • エージェントはチケットの優先度に基づいて設定された時間制限(SLA)内にソリューションを提供する必要
がある  • エージェントがSLA内で応答しない場合、顧客はチケットをエージェントのマネージャーにエスカレーションできる  • エスカレーションによりエージェントの応答時間制限が33%短縮される   • エージェントが応答時間制限の50%以内にエスカレーションされたチケットを開かなかった場合、そのチケットは自動的に別のエージェントに再割り当てされる   • 顧客が7日以内にエージェントの質問に返信しない場合、チケットは自動的にクローズされる   • エスカレーションされたチケットは顧客またはエージェントのマネージャーのみが自動またはエージェントによってクローズすることはできない  • 顧客は過去7日間に閉じられたチケットのみ再開できる  

Implementation / 実装  • ドメインモデルは振る舞いとデータの両方を組み込んだドメインのオブジェクトモデルである  • DDDの戦略的なパターン(集約、値オブジェクト、ドメインイベント、ドメインサービス)はドメインモデルの構成要素である  •
これらのパターンは全てビジネスロジックを第一に考えるという共通のテーマがある 

Implementation / 実装  • ドメインのビジネスロジックは本質的に複雑であるためドメインモデリングによって更なる複雑さが発生することはない  • モデルにはデータベースや外部システムへの呼び出しの実装など、インフラストラクチャや技術的な懸念がないようにしなければならない  •
ビジネスロジックを実装した単純なオブジェクトである必要がある  複雑さ 

Implementation / 実装  • 技術的な問題ではなくビジネスロジックに重点を置くことで、境界づけられたコンテクストのユビキタス言語に従いやすくなる  • つまりドメインモデルパターンにより、コードがユビキタス言語を「話す」ことができ、ドメインエキスパートのメンタルモデルに従うことができる  ユビキタス言語 

Building Blocks / 構成要素  DDDにおける主な構成要素として以下のような戦術的パターンがある  • Value objects / 値オブジェクト 
• Aggregates / 集約  • Domain service / ドメインサービス 

Value objects / 値オブジェクト  • 右のColorクラスの例では  ◦ いずれかのフィールドの値を変更すると新しい色になる   ◦
2つの色が同じ値を持つことはできない   ◦ 同じ色の2つのインスタンスは同じ値を持つ必要があり、色を識別するための明示的な識別子は必要ない   • 図6-1のようにcolor-idは冗長であるだけでなくバグの入り口を生んでしまう  ◦ 赤、緑、青の同じ値を持つ2つの行を作成できるが、color-id の値を比較しても、これが同じ色であることを確認できない   値の構成によって識別できるオブジェクト

Value objects / 値オブジェクト  • ビジネスドメインの概念を表現するために、言語の標準ライブラリのプリミティブデータ型のみに依存することはPremitive Obsession Code Smell
として知られている   • 例えば右のPersonクラスでは、  ◦ ほとんどの値がString型であり、landlinePhoneは固定電話番号でなければならないなどの制約がある  ◦ ユーザが常に正しい値を入力するわけではないのでクラスはすべての入力フィールドを検証する必要がある  • このアプローチの設計上のリスク  ◦ バリデーションロジックが重複する傾向がある  ◦ バリデーションロジックの呼び出しを共有することが難しい  • 以上の問題を解決するために値オブジェクトが活用できる 

Value objects / 値オブジェクト  • 明確さが増していることに注目   ◦ 例えば、country変数では完全な国名ではなく国コードを保持しているという意図を伝えるために、それを精巧にcountryCodeと命
名をする必要がない  ◦ 値オブジェクトを使うことで変数名が短くても意図を明確にできる   • バリデーションロジックが値オブジェクト自体に存在するため、割り当ての前に値を検証する必要がない   ◦ 値オブジェクトの動作は単なるバリデーションだけではない   • 値オブジェクトはビジネスロジックを一元化するときに最も輝く   ◦ まとまりのあるロジックは一か所に実装されテストが簡単   • 最も重要なのは、コードがユビキタス言語を話すようにバリデーションオブジェクトがビジネスドメインの概念を表現することである  

Value objects / 値オブジェクト  • 値オブジェクトのフィールドのいずれかを変更すると異なる値になるため、値オブジェクトは不変オブジェクトとして実装される  • MixWithメソッドを使用するこのケースのように、実行されたアクションによって新しい値が生成されると、元のインスタンスは変
更されず新しいインスタンスが返される  • 値オブジェクトの等価性は、idフィールドや参照ではなく値に基づいているため、値同士を比較する必要がある 

Value objects / 値オブジェクト  値オブジェクトはいつ使えるか  • 「いつでもいいよ」  • 値オブジェクトはコードをより表現豊かにし、ばらばらになりがちなビジネスロジックをカプセル化するだけでなく、コードの安全性も高まる 
• 値オブジェクトは不変であるため、値オブジェクトの動作には副作用がなくスレッドセーフである  • 値オブジェクトは次に説明するエンティティのプロパティに適用する  ◦ 前述のPersonクラスの例では、ID、名前、電話番号、電子メールなどに値オブジェクトを使用していた 

Entities / エンティティ  nameという1つのフィールドのみの場合、同じ名前の人が存在する可能性があり、名前だけでは人物を適切に識別できない   明示的な識別子で区別するオブジェクト識別子を導入する  • PersonIdは値オブジェクトであり、ビジネスドメインのニーズに合った任意のデータ
型(GUID、数値、文字列、社会保障番号など)を使用できる   • 識別子はエンティティの各インスタンスに対して一意である必要がある   • 識別子はエンティティのライフサイクルを通して不変のままである必要がある  

Entities / エンティティ  • 値オブジェクトとは異なりエンティティは不変ではない  • 値オブジェクトがエンティティのプロパティを記述する  • ドメインモデルの構成要素にエンティティを含めていない  ◦
含めていない理由は、エンティティは独立して実装するのではなく、集約パターンのコンテクストのみで実装するから 

Aggregates / 集約  • 集約はエンティティであり、明示的な識別子が必要であり、その状態はインスタンスのライフサイクル中に変更されることが予想される  • 集約は単純なエンティティ以上のものである  • このパターンの目的はデータの整合性を保護すること 
• 集約のデータは常に状態の整合性を維持しなければならない 

Aggregates / 集約  • データの整合性を取るために、集約とその外部スコープの間に明確な境界を引く   • 集約のロジックは、受け付けたすべての変更を検証し、その変更がビジネスルールと矛盾しないようにしなければならない  •
実装の観点から見ると、整合性は集約のビジネスロジックのみがその状態を変更できるようにすることで強制できる  • 集約の外部にあるすべてのプロセスまたはオブジェクトは集約の状態の読み取りのみが許可される  • その状態は集約のパブリックなメソッドを実行することによってのみ変更できる   整合性の強制 

Aggregates / 集約  • 集約のパブリックインターフェースとして公開される状態変更メソッドはコマンドと呼ばれることがよくある  • コマンドの実装方法  ◦ 集約オブジェクトのプレーンなパブリックメソッドとして
実装する  ◦ コマンドの実行に必要なすべての入力をカプセル化するParameter Object として実装する  ◦ どちらを選ぶかは好みの問題  • 集約のパブリックインターフェースは入力を検証し、関連するビジネスルールと不変条件を強制する  • この厳密な境界により、集約に関連する全てのビジネスロジックが一か所に実装されることが保証される  

Aggregates / 集約  • 集約に対する操作を実行するアプリケーションレイヤーは非常に単純になる  • 集約の現在の状態を読み込み、必要なアクションを実行、変更された状態を保持し、操作の結果を呼び出し元に返すだけになる 
• 11行目の同時実行チェックに注意  ◦ 複数のプロセスが同じ集約を同時に更新している場合は、後者のトランザクションが最初のトランザクションの変更を盲目的に上書きしないようにする必要がある  ◦ このような場合は2番目のプロセスは、状態が古くなっていることを通知し、操作を再試行する必要がある 

Aggregates / 集約  • 集約の永続化に使用されるデータベースは同時実行管理をサポートする必要がある  • 最も単純な形式では、集約は更新のたびにインクリメントされるバージョンフィールドを保持する方法がある  •
データベースに変更をコミットするときは上書きされるバージョンが最初に読み取られたバージョンと一致することを確認する   • このSQLでは、集約の状態に加えられた変更(2行目)を適用し、そのバージョンカウンター(3行目)を増やすが、現行バージョンが集約の状態に変更を適用する前に読み取られたバージョン(4行目)と等しい場合に限る  • 同時実行管理はリレーショナルデータベース以外でも実装できる   • ドキュメントデータベースは集約の処理に適している   • ただし同時実行管理をデータベースがサポートしていることを確認することが重要 

Aggregates / 集約  • 集約の状態は独自のビジネスロジックによってのみ変更できるので、集約はトランザクション境界としても機能する  • 集約の状態に対するすべての変更は、1つのアトミック操作としてトランザクションでコミットする必要がある  •
複数集約のトランザクション実行は想定できない   ◦ 1トランザクション1集約のみ  • 集約の境界は慎重に設計し、設計がビジネスドメインの不変条件とルールに対応していることを確認しなければならない  • 複数の集約で変更をコミットする必要があることは、間違った境界であることを示す   トランザクション境界 

Aggregates / 集約  • エンティティは独立したパターンとして使用するのではなく、集約の一部としてのみ使用する  • 複数のオブジェクトがトランザクション境界を共有する必要があるビジネスシナリオがある  ◦
例えば両方を同時に変更できる場合や、あるオブジェクトのビジネスルールが別のオブジェクトの状態に依存している場合など   • 複数のオブジェクトへの変更を1つのトランザクションで実行するために、集約パターンでエンティティの階層を表現し、すべてのトランザクションの整合性を実現する   • 階層にはエンティティと値オブジェクトが含まれ、ドメインのビジネスロジックによってバインドされている場合はそれらは同じ集約に属す   エンティティの階層 

Aggregates / 集約  • このコードサンプルでは、集約の境界に属する複数のエンティティにまたがるビジネスルールを示している   • 「エージェントが応答時間制限の50%以内にエスカレーションされたチケットを開かなかった場合、そのチケットは自動的に別のエージェ
ントに再割り当てされる」というロジックを実装している   • 集約は、すべての条件が強く整合性のあるデータであることをチェックされることを保証し、すべての変更が1つのトランザクションとして実行されるようにすることで、チェック完了後は変更されないようにする 

Aggregates / 集約  • 集約に含まれるすべてのオブジェクトは同じトランザクション境界を共有するため、集約が大きくなりすぎるとパフォーマンスやスケーラビリティの問題が発生する可能性がある   • データの整合性は集約の境界を設計するための便利な指針となる  
• 集約のビジネスロジックが強く整合性を保つために必要な情報のみが集約の一部でなければならない   • 最終的に整合性が取れればいいような情報は集約の境界の外側に存在させるべき   他の集約への参照 

Aggregates / 集約  • 集約をできるだけ小さく保ち、強い整合性を保つ必要があるオブジェクトのみ含めるようにすべき   • この例ではTicket集約はMessageのコレクションを持つ 
• 一方でCustomerやProduct、Agentは集約に属さないためIDの参照を持つ   • IDによって外部集約を参照する理由は、これらのオブジェクトが集約に属していないことを明示的にするため 

Aggregates / 集約  • 集約はエンティティの階層を表現するため、エンティティのパブリックインターフェースとして指定する必要があるのはそのうち1つだけで、それを集約のルートという   • この例では特定のメッセージを既読できるコマンドを公開し
ている  • この操作はMessageエンティティを変更するが、集約ルート Ticketを介してのみアクセスできる  • 外部の世界が集約と通信できるもう一つの仕組みとしてドメインイベントがある  集約のルート 

Aggregates / 集約  • ドメインイベントはビジネスドメインで発生した重要なイベントを表すメッセージ   • 例:  ◦ チケットがアサインされたこと 
◦ チケットがエスカレーションされたこと  ◦ メッセージを受け取ったこと etc..  • ドメインイベントの目標は、ビジネスドメインで何が発生したことを記述し、イベントに関連する必要なデータを提供すること  ドメインイベント 

Aggregates / 集約  • ドメインイベントは集約のパブリックインターフェースの一部であり、ドメインイベントを発行する  • 他のプロセスや集約、外部システムは、ドメインイベントをサブスクライブして独自のロジックを実行できる  
• このコードでは、新しいドメインイベントがインスタンス化され (12行目)、チケットのドメインイベントのコレクションに追加される(13行目) 

Aggregates / 集約  • 集約にもユビキタス言語を反映しなければならない  • 集約の名前、そのデータメンバー、アクション、ドメインイベントに使用される用語すべてに、境界づけられたコンテクストのユビキタス言語を使う  • コードは開発者間やドメインエキスパートと話すときに使用するのと同じ言
葉に紐づける 

Domain Service / ドメインサービス  • どの集約または値オブジェクトにも属さないビジネスロジック、または複数の集約に関連しているように見えるものに遭遇することがある  • このような場合ドメインサービスが使える 
• ドメインサービスはビジネスロジックを実装するステートレスオブジェクトであり、システムのさまざなまコンポーネントへの呼び出しを調整し、計算または分析を実行する  • チケット集約の例では、割り当てられたエージェントには顧客にソリューションを提案する期間が限られている   • 応答時間枠計算ロジックには複数のソースからの情報が必要   • この場合ドメインサービスとして実装することが理想  

Domain Service / ドメインサービス  • ドメインサービスを利用すると複数の集約の作業を簡単にできる  • ただし、1つのデータベーストランザクションで1つだけ変更するという集約パターンの制限を忘れないこと  •
ドメインサービスはこの制限を回避する抜け穴ではない  • ドメインサービスは複数の集約のデータを読み取る必要がある計算ロジックの実装に役立つ 

Managing Complexity / 複雑さの管理  • ビジネスマネジメントの第一人者であるEliyahu M. Goldratt氏は、   著書「The
Choice」の中でシステムの複雑さを簡潔かつ強力に定義している   • Goldratt氏によると、システムの複雑さを議論するときに、システムの振る舞いを制御および予測することの難しさを評価することに関心を持つとのこと   • これらの2つの側面はシステムの自由度に反映される   • 例えば右のコードでは一見ClassBの方が複雑そうに見えるが自由度は低い  • 振る舞いを制御および予測する上で、自由度が低いほうが簡単になる   • これがまさに集約や値オブジェクトが行うこと   • ビジネスロジックをカプセル化して保護するため自由度が低下し、複雑さに対処できる 

6-3. Conclusion / 結論

Conclusion / 結論  • 値オブジェクト  ◦ ビジネスドメインの概念でその値によってのみ識別できるので、明示的なIDフィールドは必要なく、不変なオブジェクト   ◦
データだけでなく振る舞いもモデル化する   • 集約  ◦ トランザクション境界を共有するエンティティの階層   ◦ 集約の境界に含まれる全てのデータは強い整合性が必要   ◦ 集約の状態と内部のオブジェクトは集約のコマンドを実行することによってのみ変更可能   ◦ データフィールドは外部に対しては読み取り専用   ◦ ドメインイベントを公開することで外部エンティティと通信できる   • ドメインサービス   ◦ ドメインモデルの集約または値オブジェクトのいずれにも属さないビジネスロジックをホストするステートレスオブジェクト  

6-4. Exercises / エクササイズ

Exercises / エクササイズ  1. 次のうちどれが正しいでしょう？  a. 値オブジェクトにはデータのみを含めることができる  b. 値オブジェクトに含めることができるのは振る舞いのみ  c.
値オブジェクトは不変である  d. 値オブジェクトの状態は変更される可能性がある 

Exercises / エクササイズ  2. 集約の境界を設計するための一般的な指針は何でしょう？  a. 1つの集約には1つのエンティティのみを含めることができる。また1つの集約は 1つのデータベーストランザクションに含めることができる   b.
集約はビジネスドメインのデータ整合性の要件が損なわれない限り、できるだけ小さくなるように設計する必要がある   c. 集約はエンティティの階層を表す。したがって、データの一貫性を最大限に高めるためには、集約をできるだけ広く設計する必要がある   d. ビジネスドメインによっては小さな集約が最適だが、他のビジネスドメインではできるだけ大きな集計を使用する方が効率的である  

Exercises / エクササイズ  3. 1つのトランザクションで集約の1つのインスタンスしかコミットできないのは   　なぜでしょう？  a. 高負荷下でもモデルの実行を保証できるようにするため
  b. 正しいトランザクション境界を確保するため   c. そのような要件はない。ビジネスドメインによって異なる   d. KeyValueStoreやドキュメントストアなど、複数レコードトランザクションをサポートしていないデータベースを操作できるようにするため  

Exercises / エクササイズ  4. ドメインモデルの構成要素間の関係を最もよく表しているものはどれでしょう？   a. 値オブジェクトはエンティティのプロパティを記述する   b.
値オブジェクトはドメインイベントを生成できる   c. 集約には1つ以上のエンティティが含まれる   d. aとc 

Exercises / エクササイズ  5. アクティブレコードと集約の違いについて正しいのはどれでしょう？   a. アクティブレコードはデータのみが含まれるが、集約には振る舞いも含まれる   b.
集約はすべてのビジネスロジックをカプセル化するが、アクティブレコードを操作するビジネスロジックはその境界の外側に配置できる   c. 集約にはデータのみが含まれるがアクティブレコードにはデータと振る舞いの両方が含まれる  d. 集約にはアクティブレコードのセットが含まれる  

Learning Domain-Driven Design輪読会#7

Learning Domain-Driven Design輪読会#7

kyotak

Transcript