合适的领域模型设计

给定一个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

合适的领域模型设计

回答

相关问题