はじめに
本記事は以下の書籍を読んで学んだことをまとめることを目的としています。
前回の続きです。
ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 | 成瀬 允宣 |本 | 通販 | Amazon
集約
オフジェクトの不変条件を維持する単位のことです。例えば、Userの集約にはUserIdとUserNameといったオブジェクトが含まれ、集約の外部からはUserを経由しないとUserIdとUserNameを操作することができないようにします。
このとき、Userは集約のルートと呼ばれ、UserによってUserIdやUserNameといった集約内部の不変条件を保つことができます。
Userからしかオブジェクトを操作できないようにすることで、不正なデータを防いだり、条件であったり、ルールを集約内に持たせることができます。外部にルールが点在し、変更が大量に発生することを防ぎます。
重要なのは、外部からUserが持っているUserIdやUserNameを操作するのではなく、UserがChangeNameのようなメソッドを用意し、外部から内部のオブジェクトを触れないようにしていることです。オブジェクト指向では外部から内部のオブジェクトに直接操作するのではなく、それを保持するオブジェクトに依頼することによって、直感的な実装ができ、また、不変条件を維持することにつながります。これはデメテルの法則といいます。
デメテルの法則
オブジェクト同士のメソッド呼び出しのガイドラインです。法則によるとメソッドを呼び出すオブジェクトは以下の4つに限定されるそうです。
- オブジェクト自身
- 引数として渡されたオブジェクト
- インスタンス変数
- 直接インスタンス化したオブジェクト
フィールドに対する操作はそれを保持するオブジェクトに対して命令を行い、フィールドは保持しているオブジェクト自身が管理するべきということです。
仕様
複雑な評価処理を行うオブジェクトです。単純な判定処理はメソッドとしてエンティティ・値オブジェクトに持たせればいいですが、複雑な判定処理や大量の判定処理メソッドがあると、ドメインオブジェクトの意図が見えづらくなってしまいます。
また、ドメインオブジェクトに評価メソッドが増えてしまうということは、それをほかの色々なオブジェクトから使うわけですから、オブジェクトに対する依存が増えてしまう可能性が大きくなります。
上記2点の問題点解決するために、判定処理を仕様オブジェクトに切り出すことを一度考慮してみることが重要だと思います。
仕様とリポジトリの組み合わせ
リポジトリには検索を行う様々なメソッドが定義されますが、それはドメインにとって重要なルールかもしれません。ドメインの知識がリポジトリに漏れ出すことを防ぐために仕様が使われることがあります。
ただし、仕様で検索を行うには、リポジトリからすべてのデータを取得してきて、オブジェクトを生成し、仕様オブジェクトに渡すことが必要になるので、何万件というデータに対して検索をかける可能性があるのだとすると、パフォーマンスのことも考慮に入れておく必要があります。
さいごに
ここまでお読みいただき、ありがとうございました。
今回をもって、ドメイン駆動設計入門で学んだことの記事は終了です。