3

DDD について学習しようとしていますが、エンティティとリポジトリについて理解できないことがあります。

ここでの他の質問から、リポジトリをエンティティに挿入するのは悪い習慣であることに気付きました。しかし、オブジェクトを作成しているときにリポジトリの注入を避けるにはどうすればよいですか?

簡単な状況を見てみましょう - イベントとイベント アプリケーション。これは簡単に思えます。

$event->add($application);
$eventRepository->save($event);

$application はエンティティであると信じているので、$applicationRepository が必要だと思います。

Event エンティティを保存するために $applicationRepository を $eventRepository に注入する必要があるということですか? お気に入り

class eventRepository {

    ...

    public function save(Event $event) {
        ...

        foreach ($event->applications as $app) {
            $this->applicationRepository->save($app);
        }

        ...
    }
}

私の頭に浮かんだ別の解決策はこれです：

$eventService->addAplication($event, $application);

class $eventService {

    ...

    public function addApplication(Event $event, Application $app) {

        // simple example of validation, something like $event->isAplyable()
        if ($event->capacity > count($event->applications)) {
            $this->applicationRepository->save($app);
            $event->addApplication($app);
        }

    }
}

ある方法は他の方法よりも優れていますか? それとも私はそれを完全に台無しにしましたか？

4

2 に答える 2

4

集約ルートごとにのみリポジトリが必要であり、それらは独立して機能する必要があります。

したがって、私が見ることができる 2 つのシナリオがあり、どちらを選択するかは、ビジネスのやり方によって異なります。

  1. アプリケーションとイベントが 2 つの異なる集約ルートである場合 (1 つのアプリケーションが複数のイベントに追加され、すべてのイベントが同じエンティティを参照する必要があるか?)、それらを参照を使用してデータごとに関連付ける必要があります。イベントでは、アプリケーションは保存されず、保持されているアプリケーションへの参照のみが保存されます。

  2. イベントが集約ルートであり、アプリケーションがそれと共に存続、停止、および変更される (そしてそれらが一貫性の境界を共有する) 場合、イベント リポジトリはアプリケーションをイベントの一部として保存できる必要があります。データを永続化する方法については言及していませんが、ORM はそれを支援します。

それが少し役立つことを願っています。そして遠慮なく聞いてください。

于 2013-01-09T20:02:32.213 に答える
3

アプリケーション リポジトリへの明示的な呼び出しを回避する 1 つの方法は、イベント リポジトリが、特定のイベントに関連付けられているアプリケーション インスタンスを永続化することです。これは基本的に提案する最初のオプションですが、使用する永続化フレームワークによっては、コードが少し異なる場合があります。たとえば、一部の ORM は到達可能性による永続性をサポートしています。つまり、イベントを永続化していて、フレームワークがイベントから到達可能な一時的なアプリケーション インスタンスを見つけた場合、それらも永続化します。この場合、明示的なアプリケーション リポジトリは必要ありません。

ここでのアイデアは、集約ルートのアイデアです。がEvent集約ルートであり、Applicationが構成値オブジェクトである場合、イベント リポジトリは、関連するアプリケーション インスタンスを含むオブジェクト グラフ全体を永続化できる必要があります。DDD は、必ずしもエンティティごとではなく、集約ルートごとに 1 つのリポジトリを提案しています。

Eventとの両方Applicationが集約ルート (AR)である場合があります。その場合、AR 間でオブジェクトを直接参照するのではなく、ID 参照を使用することをお勧めします。その場合、わずかに異なる形式を除いて、2 番目の例が適用されます。イベント サービスは、イベントに関連する特定のユース ケースをホストするアプリケーション サービスである必要があります。それらの 1 つは、アプリケーションの追加です。違いは、addApplicationメソッドがイベント ID とアプリケーション ID を引数として受け入れ、それぞれのリポジトリからロードすることです。また、それぞれのリポジトリを使用して、イベントとアプリケーションの両方を明示的に永続化することもできます。

ドメイン内の AR を決定する方法については、Vaughn Vernon による「Effective Aggregate Design」を参照してください。

于 2013-01-09T19:41:56.140 に答える