Как объекты, покрытые в совокупности Root, сохраняются в DDD?

Question

Прочитав много постов, я понял, что для концепции / контекста существует совокупность root, нам нужен единый репозиторий для всей этой концепции / контекста.

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

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

Кроме того, мои внутренние сущности будут go для каждой своей таблицы на уровне постоянства. Пожалуйста, исправьте меня, если мне не разрешено хранить внутренние объекты таким образом.

Пример
Считайте, что у меня есть Ресторан как совокупность root. Он может сгруппировать сущность с именем Review. Отзыв существует для ресторана и не может существовать без него.

Здесь, если Отзыв является внутренней сущностью и может быть множество отзывов о ресторане, отзывы будут сохранены в отдельной таблице. Но так как будет только один Ресторанный репозиторий для Ресторанного агрегата root, как / где обрабатывать сохранение отзывов.

Answer 1

Я хотел бы дополнить ответ CPerson.

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

В упомянутом случае я бы никогда не смоделировал Review как сущность в совокупности Ресторанов. Это не проблема постоянства, это проблема моделирования.

Существует несколько книг DDD, и я считаю, что чтения нескольких постов в блоге недостаточно для понимания как стратегий c, так и тактические схемы DDD. Одним из таких паттернов действительно является Агрегатный паттерн. Короче говоря, Агрегат - это граница согласованности. Агрегат всегда определяется контекстом c (как и все остальное).

Если вы моделируете систему управления рестораном или систему доставки еды, отзывы, вероятно, будут в отдельном контексте. Нет такого контекста, как «контекст ресторана». В этом весь смысл шаблона ограниченного контекста. В вашем примере это, вероятно, контекст обзора ресторана. То, что происходит с отзывами, не имеет ничего общего с едой, часами работы и бронированием столиков.

Если вы моделируете что-то вроде TripAdviser, у вас есть только отзывы, в основном. В таком случае рецензии более или менее агрегируют c с тем, что рецензируется. Тогда ваша модель будет совершенно другой.

Количество обзоров постоянно растет, поэтому включение всех обзоров как сущностей в какую-либо совокупность не имеет большого смысла. Опять же, Aggregate - это граница согласованности. Вы сказали бы, что отзыв не может быть опубликован, если другой отзыв - одна звезда? Я так не думаю. Какой инвариант вы пытаетесь защитить в совокупности Ресторанов относительно отзывов? Нужно ли ограничивать количество отзывов об изменении состояния ресторана на основе этих отзывов? Я не думаю, что это так. Таким образом, обзор может быть агрегатом сам по себе, поскольку все отзывы полностью независимы друг от друга.

Ресторан в агрегате обзора может представлять собой простой объект значения, содержащий идентификатор ресторана. При создании этого объекта стоимости вы должны убедиться, что данный ресторан действительно существует и открыт для просмотра. Вы действительно должны очистить отзывы, когда ресторан исчезнет. Но это также зависит от контекста c. Ресторан может закрыться, но вы все равно оставите отзывы.

Answer 2

Я согласен с некоторыми замечаниями, высказанными в других ответах о том, что вы, вероятно, не хотели бы моделировать его таким образом, но я думаю, что на ваш вопрос сам пока не ответили. И для примера это прекрасно.

Итак, вот так:

Вы не создаете репозитории (как в DDD репозиториях) для сущностей, только для совокупность root. Таким образом, в вашем примере прикладной уровень может выглядеть примерно так:

Restaurant restaurant = restaurantRepository.findById(23)
restaurant.addReview(review)
restaurantRepository.save(restaurant)

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

Агрегат сохраняется как единое целое и объекты с ним. Что происходит за хранилищем, зависит от вашей инфраструктуры. И, разумеется, поскольку хранилище принадлежит домену, нам нет дела до этой инфраструктуры.

Итак, реализация на уровне инфраструктуры (это лишь некоторые примеры того, как это может быть):

1. В documentDB у вас будет реализация репозитория, которая просто сохраняет документ в БД в целом. (Хранилища документов и DDD здесь действительно хорошо совпадают, так как aggregate = document)
2. Если бы вам пришлось сериализовать агрегат на диск в простом текстовом файле, вы могли бы иметь реализацию репозитория с сериализатором для каждой сущности, значение объект для выполнения сериализации.

3. Если у вас есть СУБД, вы действительно хотите, чтобы сущности были сохранены в их собственной таблице. Здесь вы можете использовать:

   • Каркас ORM и просто сохранить сущность root и позволить платформе автоматически сохранять / удалять / обновлять дочерние сущности
   • Использовать шаблон DAO и создавать DAO для таблицы / объекта
   • ...

Также взгляните на этот вопрос

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

Answer 3

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

Агрегат представляет границу согласованности. Если сущность принадлежит Агрегату и требуется для обеспечения согласованности, то она должна быть сохранена с Агрегатом Root.

Итак, интересно, если мне нужно будет сохранить все внутренние сущности в совокупном хранилище root, оно будет раздутым.

Да, это было бы. Вы можете рассмотреть возможность использования ORM, если это реальная проблема. ORM сохранит в памяти график с корнем в вашем Агрегате Root и обеспечит сохранение изменений по мере необходимости.

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

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