5

DDD(Blue book、Evans)によると、工場は有効な状態で集約ルートを作成する責任があります。これは、技術的なID(mongoDBの世界ではobjectId)とドメインIDを作成できるはずですか?DDDとMongoDB:MongoにObjectIDを作成させてもいいですか?

一方で、これは技術的な詳細のようで、MongoにIDの作成を処理させても大丈夫だと思われます。

一方、id(DDDリポジトリにgetByIdを持つ)によってクエリを有効にすると、技術IDがドメインに公開され、ドメインを作成することがファクトリの責任になります。

テクニカルIDとドメインIDの異なるユースケース/オーバーラップなどで私の頭を奪うことはできないかもしれませんが、おそらく私は過激ですが、とにかくあなたの意見に感謝します。

短く: DDDの場合:工場で技術IDとドメインIDを作成できるかどうか

可能な実装:ハイ/ロー(How to set the hilo sequence starting value in MongoDB Norm?

EDIT: HI/LOの方法は、唯一のリポジトリが知っておくべきものですパーシステンス層に工場を公開したが。なるほど

は感謝

+0

マイナーとは全く関係のないコメントです。 MongoDBは実際にIDを作成しません。クライアント(ドライバ)は(upsert操作を除いて)行います。 –

答えて

3

工場は、骨材の有効性は、アイデンティティと直交しているので、IDと自分自身を心配する必要はありません。 IDは、リレーショナルデータベースのインクリメンタルID(リポジトリを管理する必要がある場合)またはUUID/GUID(工場やリポジトリによって割り当てることができる場合)のいずれかとして、いくつかの方法で割り当てることができます。クライアントがデフォルトで鍵を持っているので便利です。

可能な限り、私は集約のための単一のアイデンティティを維持しようとします。私は、MongoDBが追加の技術的IDを必要とするかどうかはわかりませんが、ドメインIDを使用することができない場合、MongoDBはそれを独自に管理する必要があります。

+0

'集合の妥当性は同一性と直交しています。'確かに、有効と呼ばれる前に集合体がアイデンティティを持たなければならないことはありますか? –

+0

しかし実際には、ドメインID(工場で設定する必要がありますか?)は技術的IDではなく、それでもmongodbに別のTechnical IDを持つことが望ましい理由はありませんが、まったく別の質問だと思います。 –

+0

割り当てられたID値は、集約が永続的であることを示すことができますが、有効性は異なります。私は確かに関係を参照して、私は正当性がこの点で特別な扱いを受けると思う... – eulerfx

関連する問題