1

ソーシャル ネットワーク Web サイトの設計に DDD (ドメイン イベントを含む) と CQRS (イベント ソーシングなし) を採用しています。

UserFriendRequest、のような集約ルートがありFriendshipます。UserAddressChanged、のようなドメイン イベントもありますFriendRequestAccepted。これらのイベントの一部は、関係のあるユーザーに通知する必要があります。だから私は次のNotificationようなクラスを持つことを考えています:

public enum NotificationReason
{
    IncomingFriendRequest = 1,

    OutgoingFriendRequestAccepted = 2,

    // and many more ...
}

public class Notification
{
    public long Id { get; set; }
    public int UserId { get; set; }
    public string UserName { get; set; }
    public string AvatarUrl { get; set; }
    public DateTime Timestamp { get; set; }
    public NotificationReason Reason { get; set; }
    public bool Read { get; set; } //if user has read this notification.
}

Notificationしかし、クラスを集約ルートとしてモデル化する必要がありますか? はいの場合、User集約がアドレスを変更してUserAddressChangedドメイン イベントを発生させると、対応するイベント ハンドラで新しい集約Notificationが作成され、その後NotificationRepository. しかし、イベント ハンドラーで新しい集計を作成するのは怪しいと思います

一方、 のような単純なクラスには重すぎるようにも感じNotificationます。通知がドメインの問題なのかインフラの問題なのか判断できません。

4

2 に答える 2

1

あなたの説明から、「通知」はドメインイベントの発行(およびサブスクリプション)の実装であるように聞こえます。これは、各種類の通知がドメインオブジェクト(不変であるため値オブジェクト)に値する可能性があることを示唆しています。ドメインイベントの送受信は、集約+リポジトリよりもインフラストラクチャの問題である可能性が高い

于 2016-02-11T04:40:39.227 に答える