适当的域模型设计

Question

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

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

3. 这样的行为如何正确建模（就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的解决方案很好。