我正在努力识别Domain对象.

问题：

>公司有一个或多个站点
>网站有主要和多个联系人
>因此,公司有一个或多个联系人.这些联系人分配给站点.
>必须将联系人添加到站点而不是公司

我的理解：

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)

解决方法:

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

您的实体建模方式的答案基于您正在为其开发软件的业务系统的理解.这是DDD的重要组成部分之一 – 在了解之后进行建模,它是域驱动设计而非数据库驱动设计.

您已经在传统数据建模方面描述了您的问题,这很好但很好但不是真正的DDD.您需要在业务或运营方面描述问题.

如果没有其他领域知识,我们无法帮助您确定有效的模型.但是,作为练习,我将改变问题描述,更多地关注业务角度：

>我们公司提供现场管理服务
>公司注册网站供我们管理
>注册网站必须至少与权威机构联系,以便我们公司在现场提供服务.
>注册网站将有一个联系点,这是首选联系人.当我们公司需要与注册站点进行交互时,将首先联系此联系人.

上面的内容与您原来的“问题”相符,但现在它以这样一种方式呈现,它与(我的编制版本)商家如何看待它.对于建模过程而言,每个要点都有背景和推理.由此我们可以挑选出一些表示实体的名词：公司,网站,联系人.它还建议聚合根：站点

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

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

  public string SiteName {get}

  //--domain logic here
  / ..
}

现在关于DDD的一个很酷的事情是我们现在有更多问题要问：联系人是如何改变的？网站可以转移到新公司吗？我们需要哪些网站属性来管理它们？如何注册新网站 – 所需的最低资产是多少？这些问题的答案将导致业务应用程序远远优于简单的CRUD集合,这些集合的CRUD技术上正确的屏幕和规则集合对于最终用户来说是一个痛苦的问题.

现在说这是一个非常重要的东西,这是DOMAIN模型 – 而不是最终的数据库模型(最终看起来很像你所描述的). DDD最大的问题是带来一个基于CRUD的思维模式,这意味着程序类必须与数据库表匹配：为您的域做好准备模型不符合您的数据库模型.此外,准备好根据需要提供从数据存储中获取“哑”列表的机制,并且不要害怕将CRUD操作混合到没有实际业务价值的实体/集合.

保持开放的态度 – DDD是一个很好的模式,也是许多洞察软件开发的门户.