合適的領域模型設計

給定一個Employee實體和一堆個人/組織的相關信息（如婚姻狀況，兒童的信息，部門，位置）。是否所有個人信息都被表示爲組件/值對象，或者信息更好地駐留在實體類中？使用
會的人（這可以收集所有的個人信息）值對象爲基本對象（composition）爲Employee實體是一個糟糕的設計選擇？合適的領域模型設計
此外，如何正確建模這樣的行爲（根據DDD）：If employee has kids then it should have a birth certificate (with corresponding data: name, issue date, etc)或If employee is married then it should have marriage certificate (with corresponding data: spouse name, etc)？

對於一個孩子的情況下，我決定使用ChildrenInformation值對象：

public class ChildrenInformation 
{ 
    public String BirthCertificateCode { get;set; } 
    public DateTime BirthCertificateIssueDate { get;set; } 
    public ChildName { get; set; } 
    public ChildMiddleName { get; set; } 
    public ChildLastName { get; set; } 
    public DateTime ChildBirthday{ get; set; } 
} 

public class Employee : AbstractEntity<Employee>, IAggregateRoot 
{ 
    public ISet<ChildrenInformation> ChildrenInformation { get; set; } 

    /* other things ...*/ 
}

豈不是從設計的觀點錯了嗎？

編輯

另一種認爲是分享Certificate類。

[Serializable] 
public class Certificate 
{ 
    public String Code { get; set; } 
    public String Number { get; set; } 
    public String RegistreeName { get; set; } 
    public Address RegistreeAddress { get; set; } 
    public String RegistreeDateOfBirth { get; set; } 
    public String RegistredAt { get; set; } 
    public DateTime DateRegistred { get; set; } 
} 

[Serializable] 
public class Employee : AbstractEntity<Employee>, IAggregateRoot 
{ 
    public Certificate Passport { get; set; } 
    public Certificate MarriageCertificate { get; set; } 
    public ISet<Certificate> ChildrenBirthCertificates { get; set; } 
}

謝謝！

來源

2012-01-12 lexeme

普通法婚姻怎麼樣？他們可能沒有結婚證書，但他們的「婚姻」仍然可以作爲國內合作伙伴。 – 2012-01-13 15:23:49

@MarkKram國內關係不在這裏考慮。 – lexeme 2012-01-16 06:45:21

給定一個員工實體和大量與個人/組織相關的信息（如婚姻狀況，兒童信息，部門，職位）。是否所有個人信息都被表示爲組件/值對象，或者信息更好地駐留在實體類中？

我會把所有給出的例子作爲屬性放在員工實體中。我認爲將它們作爲價值對象沒有任何好處？

將一個人（可能收集所有個人信息）價值對象作爲一個僱員實體的基礎對象（組合）是一個糟糕的設計選擇？

這是更多的域問題。我通常不使用繼承，而是使用Customer和Employee（而不是Person實體）來分別關聯不同的模型。

來源

2012-01-13 14:21:14 jgauffin

好的！那我該如何建模這樣的行爲？ '如果員工已婚，那麼它應該有一個證書（包含代碼，日期，配偶姓名，年齡可能）'或者'如果員工有孩子，那麼它必須有每個孩子的證書'並且最後提到的證書應該包含姓名，生日日期等，所以我決定使用像「ChildrenInformation」v/o的東西。然後，員工可以儘可能多地擁有「ChildrenInformation」對象（作爲集合）。這不是錯嗎？ – lexeme 2012-01-13 14:33:37

由於DDD解決方案不是通用的，而是始終建模在特定的域之後，因此應該提供此信息。更新問題並添加問題的所有相關信息。您應該也可以添加作業標籤。 – jgauffin 2012-01-13 14:38:57

好的！這不是一項家庭作業）我很好奇DDD！ – lexeme 2012-01-13 14:42:29

我想這一點，型號：

public class Person 
{ 
    public String Name { get; set; } 
    public String MiddleName { get; set; } 
    public String LastName { get; set; } 
    public DateTime Birthday { get; set; } 
    public BirthCertificate BirthCertificate { get;set; } 
    public MarriageCertificate MarriageCertificate { get;set; } 
    // ...etc... 
} 

public class Certificate 
{ 
    public String Code { get;set; } 
    public DateTime IssueDate { get;set; } 
    // ...etc... 
} 

public class BirthCertificate: Certificate 
{ 
    public DateTime BirthDate { get;set; } 
    // ...etc... 
} 

public class MarriageCertificate: Certificate 
{ 
    public String SpouseName { get;set; } // or Spouse could also be a person 
    // ...etc... 
} 

public class Employee 
{ 
    public ISet<Person> Children { get; } 
    // ...etc... 
}

幾點：

注意的？這意味着證書是可選的。
證書值得自己的類型。如果您有多個以相同前綴開頭的屬性，大多數情況下，這意味着您可以從中定義一個對象。我還創建了一個基礎證書課程，因爲它們可能會共享一些共同的屬性和行爲。
孩子是Person對象的集合。
配偶也可以是一個人，如果你願意（該物業將被命名爲配偶）。
我不屬性名稱重複申報類型名稱：名稱，而不是PERSONNAME

來源

2012-01-16 08:33:45

關於證書的好消息！謝謝。在我看來，最好避免使用人員課程？在人員課堂內持有證書使得不可避免地使用與員工相對應的人員構成或繼承，因爲員工應該公開其婚姻狀態。由於狀態已婚/未婚和證書存在之間的依賴關係，我對此設計感到困惑。 – lexeme 2012-01-16 08:59:11

證書可能爲空/可選，因爲它是引用類型。 – lexeme 2012-01-16 11:21:07

@helicera - 好點:-)我原本爲證書考慮了一個struct，但它支持派生。我已經更新了我的答案並刪除了？ – 2012-01-16 13:37:46

請注意，組成的設計理念無關與價值類型的CLR概念。構圖僅僅意味着擁有物的生命週期必然與所有者的生命週期有關。這也可以通過引用類型實現，例如，如果擁有者是唯一擁有對擁有對象的引用。

這就是說，西蒙的解決方案很好。

來源

2012-01-16 08:51:25

合適的領域模型設計

回答

相關問題