ドメイン駆動設計: Aggregate実装チェックシート

ドメイン駆動設計で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をコールしよう。