Как идентифицировать Entities, ValueObjects и Aggregates для конкретного проекта в шаблоне DDD?

Я разрабатываю онлайн-портал вакансий, используя шаблоны DDD. Есть много «объектов», которые я выяснил, например, пользователи, должности, роли, опыт, опыт, диапазон опыта, страна, штат, город, адрес, подписки и т. Д.

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

Я принял следующее решение:

Объекты - Пользователь, Работа, Значение пакета подписки Объекты - Роль, Опыт, Диапазон опыта, Город, Штат, Страна

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

если у них есть идентификатор, не нарушают ли они фундаментальный принцип ValueObjects, и если мы не сохраняем их с идентификаторами, то как ссылаться на них в полях внешнего ключа?

Пожалуйста, помогите мне ответить на эти вопросы.

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

Заранее поблагодарив


clean-architecture domain-driven-design
person Akshay Shah    schedule 06.02.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Размышляя о DDD, оставьте отображение БД на более поздний этап. Я знаю, что повторяю то, что вы сказали, но только потому, что это правда. Объект значения может иметь идентификатор БД по другим причинам (нормализация, отчетность и т. Д.).

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

Так что еще раз забудьте о БД - подумайте об объектах. По какой причине у сущности есть идентификатор? Я бы сказал, что позже его можно будет получить и изменить, сохранив тот же идентификатор. А если это VO, это потому, что идентичность неявно присутствует в значениях объекта. Имеет ли смысл для пользователя иметь идентификатор? А как насчет адреса? Или город? ... Это зависит от обстоятельств.

Чтобы привести пример объекта значения города, если вам нужно сопоставить его как FK с таблицей «cities», тогда ваш объект City, вероятно, будет иметь идентификатор, но идентификатор не отображается. Это деталь реализации. Пока будет открыт идентификатор пользователя. Например, город может быть связан с провинцией / штатом, а город - со страной.

Но в другом приложении, где пользователи могут добавлять города и информацию о них, город может быть сущностью или даже агрегатом. Это действительно зависит от ваших требований.

Сказав это, список сущностей и ВО, которые вы предоставили, в целом выглядит нормально, но я не знаю ваших требований.

Чтобы ответить на первый вопрос: вы можете прочитать Entities, Value Objects, Aggregates and Roots, поскольку существуют некоторые правила о том, что такое VO, Entity или Aggregate. Трудность заключается в том, как их применять, и опыт - это решение.

Вкратце:

Сущности

Многие объекты в основном определяются не своими атрибутами, а скорее нитью непрерывности и идентичности.

Объекты-значения

Многие объекты не имеют концептуальной идентичности. Эти объекты описывают характеристики вещи.

Агрегаты

Агрегаты очерчивают границу вокруг одного или нескольких объектов. Агрегат применяет инварианты для всех своих Сущностей для любой поддерживаемой им операции.

person Augusto    schedule 06.02.2019