Question

我正在努力识别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我认为他的问题不止一个方面：1。如何这些对象在域驱动设计的上下文中正确匹配（DDD）aproach和他们的DDD演示是什么，例如AggregateRoot，实体，ValueObject等.2。是域的解释正确。（领域模型）

Answer 1

首先：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是一个很好的模式，也是许多洞察软件开发的门户。

实体与聚合与聚合根

1 个答案: