если стоит задача сделать api которое предоставляет  условно что на скрине в жсоне, что тогда делать?

А причем тут DDD?)))

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

в продолжение темы так сказать

Никакого отношения к апишке на чтение DDD не имеет

А касательно твоего вопроса как данные предоставить - сделай select в базу который вытянет тебе все данные, которые ты сможешь смаппить на стрктуру со скрина и вернуть

И не надо ничего городить на фабриках

хотелось бы услышать еще мнения

Поиск по чату тебе в помощь

если разбить репозитории на сбор агрегатов, и возврат энтити, то норм. более менее тоже

это лучше чем реализовывать логику сборки на стороне сервиса?

я делал нет, репозитории слой который собирает агрегаты(слой ниже) либо возвращает энтити (слой ниже). сервис уже работает с результатом репозитория. сам не делает этого. мне показалось удобно переиспользовать и развивать так

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

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

!report

Ага. Только структура данных в апишке это не модель

Обижаешь) Мы же взрослые люди. Я пытаюсь организовать свой фреймворк для проекта, пришел к выводу что, нужно делать что-то удобное. Структуру можно организовать следующим образом. 1 домен -> 1 контроллер -> 1 сервис(может иметь в зависимостях другие сервисы) -> 1 репозиторий. Допустим доменов 10 штук. У каждого есть свой репозиторий, который реализовывет интерфейс, под капотом интерфейс на свободных функциях, которые экспортируемы в рамках всего проекта. тем самым имеем удобство. Сборку сложных обьектов как раз делать внутри репозитория, а учитывая что все функции свободны нет дублирования кода. эти свободные функции можно как для транзакий так и для атомарных запросов

что об этом думешь?

не совсем понял

Человек пытается выборку на чтение сделать. Причём тут модель?