5

DDD（Blue book、Evans）によると、ファクトリは有効な状態で集約ルートを作成する責任があります。これは、ドメインIDだけでなくテクニカルID（mongoDBの世界ではobjectId）を作成できる必要があることを意味しますか？

一方では、これは技術的な詳細のようであり、MongoにIDの作成を処理させることは問題ないように思われます。

一方、IDによるクエリを有効にすると（getByIdDDDリポジトリにあることにより）、テクニカルIDがドメインに公開されます。これにより、ファクトリがIDを作成する必要があります。

テクニカルIDとドメインIDのさまざまなユースケースやオーバーラップなどに頭を悩ませることができないか、熱心に取り組んでいる可能性がありますが、とにかくあなたの意見をいただければ幸いです。

つまり、DDDの場合：ファクトリはドメインIDだけでなくテクニカルIDも作成できる必要がありますか？

可能な実装：Hi / Lo（MongoDB Normでhiloシーケンスの開始値を設定する方法は？）

編集： hi / loの方法では、ファクトリが永続層に公開されますが、これはリポジトリだけが知っておくべきことです。うーん

ありがとう

4

1 に答える 1

3

集約の有効性はIDに直交するため、ファクトリはIDを気にする必要はありません。IDは、いくつかの異なる方法で割り当てることができます。リレーショナルデータベースからの増分IDとして、リポジトリが管理する必要がある場合、またはUUID / GUIDとして割り当てることができます。この場合、ファクトリ、リポジトリ、またはクライアントがデフォルトでキーを持っているので便利な呼び出し元のクライアントですら。

可能な限り、アグリゲートの単一のIDを維持するようにしています。MongoDBに追加のテクニカルIDが必要かどうかはわかりませんが、必要であり、その場所でドメインIDを使用できない場合は、MongoDBが独自にバックグラウンドで管理する必要があります。

于 2012-08-03T04:08:59.407 に答える