Question

给定Employee实体和一堆个人/组织相关信息（如婚姻状况，儿童信息，部门，职位）。是否所有个人信息都表示为组件/值对象，或者信息更好地驻留在实体类中？
使用一个人（可以收集所有个人信息） value object 作为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; }
}

谢谢！

Answer 1

我会像这样建模：

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...
}

有些观点：

注意？用法，表示证书是可选的。
证书值得拥有自己的类型。如果您有多个以相同前缀开头的属性，大多数情况下，这意味着您可以从中定义一个对象。我还创建了一个基础证书类，因为它们可能共享一些常见的属性和行为。
Children是Person对象的集合。
配偶也可以是一个人，如果你愿意（该财产将被命名为配偶）。
我不会在属性名称中重复声明类型名称：Name而不是PersonName

Answer 2

给定员工实体和一堆个人/组织相关信息（如婚姻状况，子女信息，部门，职位）。是否所有个人信息都表示为组件/值对象，或者信息更好地驻留在实体类中？

我会将所有给定的示例作为属性放在员工实体中。我认为将它们作为价值对象没有任何好处吗？

使用一个人（可以收集所有个人信息）值对象作为Employee实体的底层对象（组合）会是一个糟糕的设计选择吗？

这更像是一个域名问题。我通常不使用继承，但使用Customer和Employee（而不是Person实体）作为彼此不相关的不同模型。

Answer 3

请注意，组合的设计概念与值类型的CLR概念无关。组合只意味着拥有对象的生命周期与所有者的生命周期相关联。这也可以通过引用类型实现，例如，如果所有者是唯一一个引用拥有对象的人。

那就是说，Simon的解决方案很好。

适当的域模型设计

3 个答案: