Proper domain model design

Question

• Given the Employee object and a bunch of personal / organizational information (e.g. marital status, information about children, department, position). Should all personal information be presented as objects / values ​​or is it better that the information is inside an entity class?

• Will using a design (which can collect all personal information) as a base object ( composition ) for an Employee object a poor design choice?

• Also, how is this behavior correctly modeled (in terms of DDD ): If employee has kids then it should have a birth certificate (with corresponding data: name, issue date, etc) or If employee is married then it should have marriage certificate (with corresponding data: spouse name, etc) ?

For the case of children, I decided to use the ChildrenInformation value object:

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

Wouldn't there be a design mistake?

EDIT

Another thought is to separate the Certificate class.

 [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; } } 

Thanks!

Answer 1

I would simulate this as follows:

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

Some moments:

• Note? the use of which means that certificates are optional.
• A certificate deserves its own types. If you have more than one property that starts with the same prefix, most of the time this means that you can define an object with them. I also created a base class of certificates, because they can have common properties and behavior.
• Children is a collection of Person objects.
• Spouse can also be a person if you want (then the property will be called Spouse).
• I do not repeat the declaration of the declaration type in the property name: Name instead of PersonName

Answer 2

Given the nature of the employee and a bunch of personal / organizational information (for example, marital status, information about children, department, position). Should all personal information be presented as objects / values ​​or is it better that the information is inside an entity class?

I would put all the given examples as properties in the employee essence. I do not see any benefit in having them as objects of value?

Is using an object (which can collect all personal information) an object-object as the base object (composition) for an Employee object, is a poor design choice?

It is rather a domain issue. I usually do not use inheritance, but I use Customer and Employee (instead of the Person object) as different models that are not related to each other.

Answer 3

Note that the concept of composition design has nothing to do with the concept of CLR type values. Composition simply means that the life of his property is tied to the life of the owner. This can also be achieved using reference types, for example, if the owner is the only one having a reference to the object belonging to him.

However, the solution from Simon is perfect.