для команд как правило нужно не оч много стэйта за раз. А для UI - много. Разумеется можно полагаться на самоконтроль и тогда "да можно" просто в контексте работы в команде люди будут оч любить тянуть UI штуки в агрегаты потому что так удобнее и проще

банально разные требования... command - целостность данных, отсутствие shared state, изоляция бла бла. UI - мы можем сразу забить на вопросы "а данные у нас точно актуальны?" потому что они всеравно не гарантированно актуальны когда доходят до UI

Понял. Спасибо

А еще вопрос. На каком уровне надо поддерживать CQRS?

Вот например с фронтенда приходит запрос на обновление  какого-нибудь REST ресура.

Я могу обратно отправить обновленные данные? Если да, то как их получать? Из агрегата?

Или делать запрос Query внури application сервиса через DAO? В таком случае у меня чтение может идти из реплик у которых данные еще не обновились.

Зачем обратно отправлять данные они и так знают что они отправили.
Если это просто обновление то CRUD хватит. Зачем там CQRS

Ну, например, при обновлении еще что-то подсчитывается

не надо применять CQRS там где тебе надо знать результат операции.

суть CQRS в том "как выстроить процесс что бы не ждать"

"что бы команда если была принята сервером выполнилась". При этом "email в котором извеняются что твоя бронь не забронилась" это вполне себе "выполнилось"

рекомендую на тему CQRS смотреть уди

ищи по чату ссылку на ADSD

Хорошо. Посмотрю. Уже натыкался на его блог

Получается CQRS можно применять выборочно

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

скорее даже нужно
и по ходу это не только к CQRS относится

Кстати, по поводу того что и когда использовать.

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

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

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

А что имеете ввиду под "как для чтения, так и для бизнес транзакций"? В больших проектах где агрегаты/чистая архитектура юзаются по полной это не так?

Вопрос же в стоимости. Лучше конечно, но надо ли. Маленький проект может жить и с не очень хорошими тестами ))

Просто вот как тогда сделать маленький проект, но поддерживаемый и тестируемый?) И чтобы в будущем можно было легко допилить его до уровня сложной бизнес логики

Ну вот я выше спрашивал по CQRS. Как я понимаю, агрегаты не выгодно использова для запросов. Больший расход памяти на создание объектов с логикой, которая не будет использована, + выборка ненужных данных

просто начать его делать правильно и все 🙂
у нас есть граспы, солиды и ооп которые помогут сделать красиво и без изощерений