Я не понимаю почему не агрегат. Все равно же захочется сделать тестируемым. Захочется обращения к бд выделить в репозиторий. И получится что-то вроде агрегата

нет, на запись тоже

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

Будет сущность данных, а не бизнеса

потому что не надо усложнять. человеку по факту надо собрать DTO нужной структуры с нужными данными.

и да - агрегаты ТОЛЬКО на запись. На чтение агрегаты бессмысленны (у тебя нет транзакций что бы давать им границы консистентности)

а то "все агрегаты"...

а почему все должно быть "сущностью бизнеса"?

Можно было бы посмотреть в сторону cqrs, но наверное это будет оверхед для данной задачи

блин ребят, вы сча серьезно?)))

Так я не говорю, что все сущность бизнеса

Согласен, советовать агрегаты было глупо

агрегаты, CQRS и вот это все имеет смысл советовать там где колаборативный домен

а тут просто sql запросик и данные замэпить, ну рили

Так он спросил как ему несколько сущностей в одну собрать ¯\_(ツ)_/¯

ну да, так и спросил )

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

Но я еще плохо разбираюсь *

спасибо всем за помощь и советы 🙌

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

Агрегаты не про агрегацию.