Поиск DDD как сущность или объект значения

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

В качестве введения некоторые упрощенные задачи должно выполнять мое приложение. Это приложение для бронирования курсов:

  • Курс состоит из категории, даты и времени, описания и местоположения.
  • Категории и местоположения можно выбрать в раскрывающемся списке.
  • Специальный раздел настроек дает пользователю возможность добавлять и изменять категории и местоположения.

Я немного запутался в неизменном состоянии объекта. Сначала я подумал, что, например, размещение должно быть объектом-сущностью, потому что оно имеет идентичность. Но по объему, конечно, само местоположение неизменно и не может быть изменено.

Я действительно смущен. Может ли кто-нибудь помочь мне прояснить мое мнение?


design-patterns lookup domain-driven-design value-objects
person Dirk Beckmann    schedule 22.11.2013    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Если локациями можно управлять независимо от курсов (добавлять, редактировать, удалять и т. д.), то локации, скорее всего, являются независимым совокупным корнем. Вы бы изменили свой курс, чтобы он ссылался на идентификатор своего местоположения, а не содержал местоположение.

Я бы сделал это, поскольку местоположения ограничены, вы, вероятно, захотите рассмотреть их моделирование как сущности (т.е. это то, что вы собираетесь хранить и использовать для идентификаторов, а не что-то вроде домашних адресов студентов, которые, скорее всего, всегда будут объектами-значениями, поскольку они не имеют возможности изменения или повторного использования), с местоположением в качестве совокупного корня, с каждым местоположением, имеющим свойство адреса, которое будет объектом-значением (если вы используете SQL, тогда адрес может быть денормализованы и сохранены в строке с данными о местоположении).

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

person Adrian Thompson Phillips    schedule 22.11.2013

arrow_upward
0
arrow_downward

Решение основано на том, как вы их идентифицируете (не неизменность).

Местоположение обычно является сущностью. Но в некоторых случаях объект значения также подходит, если вам нужен только идентификатор.

@Entity
Location {
    @Identifier private String code;

    //many other mutable properties
}

@ValueObject
Location {
    private String code;//the only property
}

DDD не подходит для таких областей, как информация о продукте или другие вещи, ориентированные на управление контентом. Я бы предпочел сохранить исходную структуру, но найти небольшой поддомен для рефакторинга, например, инвентарь или цены.

person Yugang Zhou    schedule 23.11.2013

arrow_upward
0
arrow_downward

Категория и местоположение являются примерами того, что Вон Вернон называет стандартными типами в своей книге Реализация дизайна, ориентированного на предметную область. Хотя обсуждение в книге находится в Главе 6 — Объекты-значения, он предлагает, чтобы стандартный тип был сущностью в его родном BC, и мы должны попытаться рассматривать их как ВО в потребление БК:

Мы можем думать о них как о Сущностях, потому что они живут своей собственной жизнью в выделенном, родном Ограниченном Контексте. Независимо от того, как они создаются и поддерживаются каким-либо органом по стандартизации, по возможности мы должны стремиться относиться к ним как к ценностям в нашем контексте потребления. [...]

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

(Кстати, Вернон упоминает, что этот тип объекта, который он называет стандартным типом, также известен как lookup и код типа.)

person Paulo Merson    schedule 20.02.2019