【问题标题】:DDD: How to handle multiple possible aggregate root linksDDD:如何处理多个可能的聚合根链接
【发布时间】:2017-09-14 17:04:57
【问题描述】:

我正在使用 DDD 开发帮助台应用程序。我的问题是如何最好地处理可以引用两个可能的 AR 的实体。

我有一个RequestSubscriber 订阅请求更新的人。

此订阅者是AgentContact

问题是——我应该有一个对代理或联系人的可选引用并且只填写一个还是有一个具有关联类型的通用人员引用以确保链接到达正确的位置?

模型选项:

// This
public class RequestSubscriber : DomainEntity, IPerson
{
    // Constuctors...

    public Guid? Agent_Id { get; private set; }
    public Guid? Contact_Id { get; private set; }
    public SubscriberType Type { get; private set; }
    public Email Email { get; private set; }
    public PersonName Name { get; private set; }
}

// Or This
public class RequestSubscriber : DomainEntity, IPerson
{
    // Constuctors...

    public Guid Person_Id { get; private set; }
    public SubscriberType Type { get; private set; }
    public Email Email { get; private set; }
    public PersonName Name { get; private set; }
}

建造者:

    // This
    public RequestSubscriber(Guid id, Request request, IPerson person) : base(id)
    {
        Guard.ForNull(request, nameof(request));
        Guard.ForNull(person, nameof(person));

        if(person is Agent agent)
        {
            Email = agent.Email;
            Name = agent.Name;
            Type = SubscriberType.Agent;
        }
        else if (person is Contact contact)
        {
            Email = contact.Email;
            Name = contact.Name;
            Type = SubscriberType.Contact;
        }
        else
        {
            throw new ArgumentException("Subscribers must be an agent or contact", nameof(person));
        }

        request.Subscribe(this);
    }

    // Or This
    public RequestSubscriber(Guid id, Request request, Agent agent) : base(id)
    {
        Guard.ForNull(request, nameof(request));
        Guard.ForNull(agent, nameof(agent));

        Email = agent.Email;
        Name = agent.Name;
        Type = SubscriberType.Agent;

        request.Subscribe(this);
    }

    public RequestSubscriber(Guid id, Request request, Contact contact) : base(id)
    {
        Guard.ForNull(request, nameof(request));
        Guard.ForNull(contact, nameof(contact));

        Email = contact.Email;
        Name = contact.Name;
        Type = SubscriberType.Contact;

        request.Subscribe(this);
    }

【问题讨论】:

  • 另外一个想法是,也许我真的应该有两个不同的订阅者——代理订阅者和联系人订阅者。
  • 我想念你提到的Subscriber 课程。 RequestSubscriber 是什么类型的 IPerson 为什么以及如何影响它?该 AR 保护的不变/一致性边界是什么?
  • 抱歉,RequestSubscriber 是订阅者类名。这主要是因为Contact 的电子邮件通知与Agent 不同。
  • 在这种情况下,我将使用第二种方法(类型标志)。

标签: domain-driven-design aggregate


【解决方案1】:

一个选项可能是添加另一个间接级别:)

您的RequestSubscriber 似乎汇集了RequestSubscriber。您传入了 Request,但 Subscriber 部分中可能缺少一个概念。

同样,Request 抽象出任何请求是您的Subscriber 可以抽象出您的订阅者代表的任何内容。

如果您需要SubscriberType 还有其他原因,那么它可能会改变实现方式。

【讨论】:

  • 我想到了这一点,IMO 会将问题从RequestSubscriber 代理到Subscriber
  • 啊,我重新阅读了您的评论,您确实提到了这一点。这将取决于一个人要移动的实际问题是什么。
猜你喜欢
  • 1970-01-01
  • 2021-07-22
  • 2016-03-21
  • 2016-03-29
  • 2015-01-04
  • 2016-11-29
  • 1970-01-01
  • 2011-01-13
  • 1970-01-01
相关资源
最近更新 更多