Правильный дизайн модели предметной области - PullRequest
Новая
       10

Правильный дизайн модели предметной области

4 голосов
/ 12 января 2012
  1. Учитывая Employee сущность и кучу личной / организационной информации (например, семейное положение , информация о детях , отдел , 1010 * положение *).Должна ли вся личная информация быть представлена ​​как компоненты / объекты-ценности, или лучше, чтобы информация находилась внутри класса сущности?

  2. Будет ли использоваться человек (который может собрать всю личную информацию) Значение объекта в качестве базового объекта (composition) для объекта Employee будет плохим выбором дизайна?

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

Спасибо!

Ответы [ 3 ]

4 голосов
/ 16 января 2012

Я бы смоделировал это так: 

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

Некоторые баллы:

  • Обратите внимание на? использование, что означает, что сертификаты не являются обязательными.
  • Сертификаты заслуживают своих собственных типов. Если у вас есть несколько свойств, которые начинаются с одного и того же префикса, в большинстве случаев это означает, что вы можете определить объект по ним. Я также создал базовый класс Certificate, поскольку он может иметь некоторые общие свойства и поведение.
  • Children - это коллекция объектов Person.
  • Супруг (супруга) также может быть человеком, если хотите (тогда это имя будет называться супругом).
  • Я не повторяю объявление имени типа в имени свойства: Name вместо PersonName
0 голосов
/ 16 января 2012

Обратите внимание, что концепция дизайна композиции не имеет ничего общего с концепцией CLR типа значения. Композиция просто означает, что время жизни принадлежащего объекта связано с временем жизни владельца. Этого также можно достичь с помощью ссылочных типов, например, если владелец является единственным, у которого есть ссылка на принадлежащий объект.

Тем не менее, решение от Саймона просто отлично.

0 голосов
/ 13 января 2012

Учитывая сущность Сотрудника и кучу личной / связанной с организацией информации (например, семейное положение, информация о детях, отдел, должность).Должна ли вся личная информация представляться в виде компонентов / объектов-значений или лучше, чтобы информация находилась внутри класса сущности?

Я бы поместил все приведенные примеры в качестве свойств сущности сотрудника.Я не вижу никакой выгоды в том, чтобы иметь их в качестве объектов значений?

Было бы использование объекта значения человека (который мог бы собрать всю личную информацию) в качестве базового объекта (композиции) для сущности Сотрудник?bad design choice?

Это скорее вопрос домена.Я обычно не использую наследование, но использую Customer и Employee (вместо сущности Person) в отношении разных моделей, не связанных друг с другом.

...