實體vs聚合vs聚合根

問題：

一個公司有一個或多個位點
網站具有主要和多個接觸
因此，一個公司有一個或多個觸點。這些聯繫人分配給網站。
聯繫人必須添加到站點而不是一個公司

我的理解：

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）的形式給出的背景下，什麼是他們的DDD的介紹，例如AggregateRoot，實體，ValueObject等。2.域的解釋是否正確。（領域模型）

來源

2014-10-08 MJK

只要按照說明鍵入。你創建一個鏈接表'CompanySites'，這是一個多對多的關係，但是你解釋它的方式，'Site'只需要一個'CompanyId'，'Company'需要一組'Site'。 – Silvermind 2014-10-08 16:24:32

@Silvermind所以你認爲不需要CompanySites或聚合根？只需要在網站類中添加公司ID。 – MJK 2014-10-08 16:33:44

是的，@AydinAdn有一個恰好反映你的解釋的例子。 – Silvermind 2014-10-08 18:26:18

第一個：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收集技術上正確的屏幕和規則集合，這對於最終用戶來說是一件痛苦的事情。

現在，在這裏陳述這是DOMAIN模型 - 而不是最終的數據庫模型（最終會看起來如何描述）。 DDD最大的問題是要引入基於CRUD的思維模式，這意味着程序類必須與數據庫表匹配：爲您的域模型做好準備，不要與您的數據庫模型匹配。另外，準備好提供機制，根據需要從數據存儲中獲取「愚蠢」列表，並且不要害怕將實體/集合的CRUD操作混合在一起，而沒有真正的商業價值。

保持開放的態度--DDD是一個偉大的模式，是深入瞭解軟件開發的入口。

來源

2016-08-15 01:16:11 Joe

實體vs聚合vs聚合根

回答

相關問題