c# - 实体 vs 聚合 vs 聚合根

Question

我正在努力识别域对象。

问题:

• 一家公司有一个或多个站点
• 一个站点有主要和多个联系人
• 因此，一家公司有一个或多个联系人。这些联系人分配给站点。
• 联系人必须添加到站点而不是公司

我的理解:

public class Company : IEntity
    {
         public int CompanyId {get;}
         public string CompanyName {get;}
         //.....
    }

    public class Site : IEntity
    {
         public int SiteId {get;}
         public string SiteName {get;}
         //.....
    }

    public class Contact : IEntity
    {
        public int ContactId {get;}
        public string SurName {get;}
        public bool MainSiteContact {get;}//Confused!! May be this is not the right place
         //.....
    }

    public class SiteContact : IAggregate
    {
        public Site ASite { get; }
        public List<Contact> Contacts { get; }
        public Contact MainContact {get;}//Confused!! 
        //.....
        public Contact AddSiteContact(...)
        {
        }
    }

    public class CompanySites : IAggregateRoot
    {
        public Company ACompany { get; }
        public List<Site> Sites { get; }
        public List<SiteContact> Contacts { get; }
        //.....
    }

我的方向对吗？如果我错了请纠正我...

更新@Beachwalker 在@Aydin Adn 的回答下方的评论部分中适本地阐述了这个问题。

@Aydin Adn I think his questions has more than one aspects: 1. How these objects fit correctly in the context of a Domain Driven Design (DDD) aproach and what is their DDD presentation, e.g. AggregateRoot, Entity, ValueObject etc. 2. Is the interpretation of the Domain correct. (Domain Model)

Answer 1

第一个:https://www.infoq.com/minibooks/domain-driven-design-quickly - 阅读什么是 DDD 和无处不在的语言章节 3 遍。

实体建模方式的答案基于对您为其开发软件的业务系统的理解。这是 DDD 的重要部分之一 - 建模是在理解之后进行的，它是领域驱动设计而不是数据库驱动设计。

您已经根据传统数据建模描述了您的问题，这很好但不是真正的 DDD。您需要用业务或运营术语描述问题。

如果没有额外的领域知识，我们无法帮助确定有效的模型。但是，作为练习，我将更改问题描述以更多地关注业务角度:

1. 我们公司提供网站管理服务
2. 公司注册网站供我们管理
3. 注册网站必须至少有一个与当局的联系点，以便我们公司能够在网站上执行我们的服务。
4. 注册站点将有一个联系人，即首选联系人。当我们公司需要与注册网站互动时，将首先联系此联系人。

上面的内容与您原来的“问题”相符，但现在它的呈现方式与(我编造的)企业对它的看法一致。每个点都有上下文和推理，这对建模过程至关重要。由此我们可以挑出一些表示实体的名词:Company、Site、Contact。它还建议聚合根:站点

class Site : IEntity, IAggregate {
  public SiteKey Key {get}

  public CompanyKey CompanyKey {get}
  public ContactKey PrimaryContactKey {get}
  public IEnumerable<ContactKey> ContactKeys {get}

  public string SiteName {get}

  // domain logic here
  // ...
}

现在 DDD 最酷的地方在于我们现在有更多问题要问:联系人是如何更改的？可以将站点移动到新公司吗？我们需要网站的哪些属性来管理它们？新站点如何注册 - 所需的最低属性是什么？这些问题的答案将产生比简单的 CRUD 集合更优越的业务应用程序，这些集合在技术上是正确的屏幕和规则集合，最终用户处理起来很痛苦。

现在非常重要的是要在这里声明这是 DOMAIN 模型 - 而不是最终的数据库模型(最终看起来与您描述的差不多)。 DDD 最大的陷阱是带来基于 CRUD 的思维方式，这意味着程序类必须与数据库表匹配:为您的域模型做好准备，而不是与您的数据库模型匹配。此外，准备好根据需要提供从数据存储中获取“哑”列表的机制，并且不要害怕将没有实际商业值(value)的实体/集合的 CRUD 操作混合在一起。

保持开放的心态 - DDD 是一种很好的模式，也是通往软件开发许多见解的途径。