В DDD являются ли репозитории единственным типом классов, которые могут касаться постоянства?

Question

В DDD совокупные корни сохраняются через репозитории. Но являются ли репозитории единственными классами, которые могут касаться постоянства в ограниченном контексте?

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

Кроме того, я использую события домена, некоторые события домена также должны быть сохранены. Мне нужно нечто, называемое хранилищем событий, но я только слышал, что такие термины появляются в источнике событий (ES), и я не использую ES.

Если такие постоянные классы действительно нужны. Как мне их назвать, к какому слою они должны принадлежать?

[Обновить]

Когда я прочитал ответы ниже, я понял, что мой вопрос немного двусмысленный. На ощупь я в основном имею в виду запись (и в том числе чтение).

Благодарю.

Answer 1

На стороне запроса такие вещи, как количество просмотров, upvotes, эти вещи должны быть сохранены

Не обязательно. CQRS не указывает

• должна ли материализованная модель считываться в ее собственной базе данных
• как обновляется читаемая модель

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

Вы можете увидеть минималистичную - но в то же время полностью совместимую с CQRS - реализацию здесь: https://github.com/gregoryyoung/m-r/tree/master/SimpleCQRS

Но являются ли репозитории единственными классами, которые могут касаться постоянства в ограниченном контексте?

Нет, в контексте CQRS, Read Model Facades (так называемые репозитории со стороны чтения) также может читать из него, и ваш механизм обновления модели чтения записывает в него.

Кроме того, я использую события домена, некоторые события домена также должны быть сохранены. Мне нужно нечто, называемое хранилищем событий, но я только слышал, что такие термины появляются в источнике событий (ES), и я не использую ES.

Хранилища событий являются основной технологией хранения событийных систем. Вы можете использовать их для хранения нескольких доменных событий в стороннем приложении, но они могут быть излишними и слишком сложными для этой задачи. Это зависит от того, нужны ли вам все гарантии, которые они предлагают в плане доставки, согласованности, параллелизма / управления версиями и т. Д. В противном случае обычное хранилище СУБД или NoSQL может сработать.

Answer 2

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

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

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

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

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

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