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

Ну ДАО это не про рид модель, а про write в моем понимании. Для клиента делаем отдельную Read модель, в которой может быть вагон джойнов, кеши и другие изошьрения.

Приветствую. Такой банальный вопрос, есть у меня в бд класические таблички "orders" и "order_items", во второй есть айди товара, количество и айди заказа. Вопрос: поскольку клиент моего api конечно же желает получить заказ одной сущностью (т.е. внутри заказа массив items а там массив товаров заказа из второй таблицы), то на каком уровне/слое/абстракции у меня в приложении должно происходить построение целой сущности заказа (join + объединение массива товаров заказа в сам заказ). Учитывая то что и внутри бизнес юзкейсов всяких может потребоваться работать как с самим заказом, так и с его содержимым.

А какие юзкейсы есть, в которых требуются разные данные из этих таблиц?

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

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

Ну и встречный вопрос, как это лучше реализовать на уровне доступа к бд, делать
1) select from order_items where order_id = ?
Или
2) select + join и в приложении "мерджить" это в один объект

Ну для потребителя апи это отдельная история, ему может захотеться пол базы отдать в запросе. Это не значит, что у тебя всё должно быть одной куче. Просто собрать данные из разных контектов для отображения в Read model

Имелось ввиду банальный GET /api/orders/123

Последнюю фразу чесно говоря не понял

Ну отдать ты хотешь не только ресурс ордера, но ещё много чего?

Ресурс ордера + все товары в нем

Данные, зависимости для бизнес юзкейсов и для отображения на ui(отдачи по api) совершенно разные.
Их лучше разделить в write и read model

Ну для отдачи клиенту лучше выбрать самый быстрый и эффективный способ. Думаю это будет join

Ок, тогда еще уточнение к теме выше, где этот join должен быть? Dao/repository? Или это тоже самое? Вашей терминологии "read/write model" не понял, можете подскажите где об этом почитать

read/write - это про CQRS и CQS можно почитать

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

Для отдачи клиенту я бы сделал отдельные модули, которые собирают инфу напрямую с базы.

++))

Ну советуем мы красивые теории, а работаем с говнокодом. Так что так и есть)

Для моего проекта это будет оверинжениринг