ドメイン駆動設計でAggregate(集約)を実装するためのチェックシートです。
□ トランザクション分析をしてトランザクションの単位でAggregateを実装しているか?
単にツリー構造や分類学的にAggregateを作っているとしたら正しくない。
Entityを複数含むAggregateを作っている場合は、トランザクション分析していない可能性があるため、
ユースケースを確認しビジネス上のトランザクション分析を行う。
□ Aggregateの大きさは大き過ぎないか?
もし、Aggregateが複数のEntityを含んでいる場合は、
EntityをValue Objectにすることができないか、
直接参照ではなくEntityをAggregate Rootに昇格しIDによって参照する設計にできないかを検討する余地がある。
□ 他のAggregateは直接参照ではなく、IDによって参照されているか?
もし、Aggregate が他のAggregateを直接参照している場合は、
IDを表現したValue ObjectをそのAggregateの代理として参照できないか検討する。
□ 複数のAggregateが同時に変更される場合にDomain Eventを使っているか?
Application Serviceにて、ひとつのトランザクションで複数のAggregateを更新している場合は、
Domain Eventのパターンが利用できないか検討する。
□ ひとつのEntityをAggregate Rootとしてモデリングしているか?
どのEntityがAggregate Rootかを認識すること。
□ そのAggregateはグローバル空間での一意なIDを持っているか? UUIDなど。
□ Aggregateの部品はEntityではなくValue Objectにできるかどうか検討したか?
□ クライアントには最低限の知識のみ提供されているか? Tell, Don't Ask原則のガイドラインに従っているか?
そのAggregateがテストしにくかったり、メンテナンスが難しいとしたら、
必要以上にクライアントに知識が漏洩している可能性がある。
Command(更新)とQuery(問い合わせ)の分別をつけ、
クライアントがCommandの条件分岐のためにQueryをしていないかチェックする。
□ RepositoryやDomain ServiceをAggregateにDependency Injectionしていないか?
Aggregateのオブジェクトは沢山つくられつため、DIは潜在的なパフォーマンスを損なう。
複数のAggregateに問い合わせる場合は、Application ServiceでそれぞれのRepositoryをコールしよう。