2

まず、私は DDD の初心者であり、「青本」を読む必要があることを認めます。

「Match」タイプの AggregateRoot を持つシステムを構築しています。各試合は「投票」のコレクションを持つことができ、ユーザーが試合に賛成票または反対票を投じると増加する読み取り専用の「VoteCount」プロパティもあります。

多くのユーザーが同時に試合に投票する可能性があるため、投票は試合に追加/削除する必要があり、VoteCount は書き込みロックを含む 1 つのアトミック操作としてインクリメント/デクリメントする必要があります (ロックは DB によって処理されます)。(他のプロセス/コンポーネントから効率的にクエリを実行するには、データベース内の静的な値として VoteCount が必要です。)

厳密な DDD に準拠している場合、この操作を次のようにコーディングするように思えます。

アプリケーション サービスは、投票要求オブジェクトを受け取ります。サービスは、Match リポジトリから Match オブジェクトを取得します。サービスは、Match オブジェクトに対して何らかのメソッドを呼び出して、Vote をコレクションに追加し、VoteCount を更新します。その後、リポジトリはその Match インスタンスを DB に保持します。ただし、このアプローチは、次の 2 つの主な理由から、私のアプリケーションでは実行できません。

バックエンドで MongoDB を使用していますが、この読み取り/書き込み操作をトランザクションにラップして、Match データとそれに関連する Vote および VoteCount のダーティ リードを防ぐことができません。

非常に非効率です。Vote を追加して VoteCount をインクリメントするためだけに、オブジェクト グラフ全体を引き戻しています。これは、リレーショナル データベースよりもドキュメント データベースの方が効率的ですが、まだ不要な読み取り操作を行っています。

問題 1 と 2 は、単一の Vote オブジェクトをリポジトリに送信し、Mongo に対して 1 つのアトミックな更新ステートメントを実行する場合には問題になりません。

この場合、投票は「集計」と見なされ、独自のリポジトリと集計ステータスに値するでしょうか?

4

2 に答える 2

2

この場合、投票は「集約」と見なされ、独自のリポジトリと集約ステータスに値するでしょうか。

これが正しい答えかもしれないと思います。アグリゲートは、トランザクションの一貫性の境界である必要があります。試合の投票間に一貫性の要件はありますか？マッチアグリゲートの投票コレクションのプレゼントは、あることを示唆します。しかし、ある投票は次の投票とは何の関係もないようです。

代わりに、各投票を個別に保存します。このようにして、MongoDBの集約機能を使用してカウントを取得できますが、それでも遅いかどうかはわかりません。そうである場合は、Map/Reduce機能を使用して集計できます。

より一般的には、これはDDDに最適ではない場合があります。ドメインが複雑な動作で構成されていない場合、DDDの戦術パターン（エンティティ、アグリゲート）をこのドメインに適合させようとする理由はほとんどありません。

于 2013-02-01T01:02:47.453 に答える
1

はい、 Voteをそれ自体の集約としてモデル化できます。現実の世界では、人々は一度に複数のことに投票することがよくあります。集計は、投票の代わりに投票と呼ばれます。一度に投票できる項目が 1 つしかないという特殊なケースがあります。

私は MongoDB について話すことはできません (おそらく他の誰かができるでしょう)。

public class Match
{
    public string Id { get; set; }
    public string Name { get; set; } // or whatever
}

public class Vote
{
    public string Id { get; set; }
    public string MatchId { get; set; }
    public string UserId { get; set; }
    public bool YeaOrNay { get; set; } // or whatever
}

次に、投票に対して map/reduce インデックスを作成して、結果を集計します。

于 2013-02-01T00:35:57.817 に答える