Лучший способ создать модель дизайна домена?

Question

ОБНОВИТЬ:

то, что я ищу, я должен создать каждый класс отдельно, вместо того, чтобы добавить в класс поддержку getter / setter, что я имею в виду под этим:

поэтому, чтобы создать Визит, я должен иметь следующую опору в VISIT

VisitName, Purpose, StartDate, EndDate, HostId, HostName, RequesterId, RequeserName

или я должен иметь это:

VisitName, Purpose, StartDate, EndDate, IPerson Host, IPerson Requester

КОНЕЦ ОБНОВЛЕНИЯ

Мне нужен совет / обратная связь, если я иду в правильном направлении, ниже приведена модель предметной области (часть проекта не до конца).

У меня есть класс под названием "Визит" в этой модели посещения, у меня будут базовые данные о посещении, такие как имя, цель, начало, дата окончания и т.д.

что вы думаете о нижнем классе?

 //aggreate class
public class Visit
{
    IVisitBasic _visitBasic;
    IPerson _host;
    IPerson _requester;

public IVisitBasic VisitBasic
{
    get { return _visitBasic; }
    set { _visitBasic = value; }
}

public IPerson Host
{
    get { return _host; }
    set { _host = value; }
}

public IPerson Requester
{
    get { return _requester; }
    set { _requester = value; }
}

public Visit(IVisitBasic visitBasic, IPerson host, IPerson requester)
{
    _visitBasic = visitBasic;
    _host = host;
    _requester = requester;
}

public Visit() { }

}

Answer 1

Вначале все выглядит хорошо, но я бы не стал создавать жесткую и быструю модель предметной области, пока вы не начнете кодировать и тестировать исходную модель предметной области, поскольку вы, вероятно, обнаружите, что все работает не совсем так, как ожидалось, или что-то такое, что вы пропустили или изменились требования и т. д.

Другие моменты из быстрого просмотра.

• Какова цель VisitBasic, должен ли он быть абстрактным базовым классом или более понятным именем?
• Возможно, вы захотите превратить хост в свой собственный класс, он может иметь информацию, не относящуюся к классу человека, поэтому, возможно, подкласс человека. Но, как указано выше, может быть, лучше развивать его итеративно. И, возможно, заказчик, но, вероятно, менее вероятно.

ОТВЕТ ОБ ОБНОВЛЕНИИ. В настоящее время для большинства вещей стандартным дизайном является добавление сервисного уровня, то есть VisitService с методом createVisit, а свойства объекта посещения должны просто ссылаться на хост и запросчик без какой-либо бизнес-логики в них. (Надеюсь это ответит на твой вопрос?)