Простейшая задача: Симфа, доктрина, пилим блог по DDD. Есть посты и они

на разных языках. Т.е. по-факту пост - это агрегат, который содержит в себе основную инфу + несколько переводов.

Внимание вопрос:
Если постов 100штук и нужен запрос «вывести все посты с их содержимым на рус языке»...
то в доктрине это будет один запрос на select from posts. И потом внутри каждого поста будет ещё +1 запрос на select translate where post_id = ?? (Итого +100 запросов)

Или есть какой-то более быстрый вариант с join?

Не, джоин нельзя, не по ддд

«База вышла из чата» ☹️

После разума, который вышел после того, как ты задал свой вопрос

Ну серьезно, при чем тут ддд и как достать посты? Ей богу, каждый раз одно и то же, где ваш мозг отдыхает, когда вы вопросы такие задаете?

Так объясни, раз ты такой умный! Со сразу троллить?

Может вы ответите человеку? Не нужно быть таким токсичным чсв

Ок. Допустим чтение без доктрины (например чистый Raw запрос на выходе которого массив) Тогда объясните 2 момента: 1) Ты когда делаешь поиск одного поста (чтение) то из базы тебе в итоге нужно получить объект, чтобы как-то с ним работать. (По DDD) Те нужно ручками писать маппер, который будет массив превращать в объект поста? 2) я делаю пост нескольких постов с рус переводом и джойном: мне в итоге теперь нужно работать с массивом неструктурированных данных (ибо не объекты) или опять писать ручками маппер на РАСШИРЕННЫЙ пост, содержащий в себе поле перевода?

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

Хорошо. А если это не блог с постами, а платёжи с ежемесячными подписками , транзакциями и бизнесс-логикой. Тогда что?

Запись отдельно, чтение отдельно. У чтения нет бизнес логики, потому что ничего не меняется

Откуда у тебя бизнес-логика при отображении списка?

Человек написал другую задачу. Нужно читать внимательно, прежде чем просить кого-то включить голову

Я не говорил, что это отображение списка. Это может быть получение списка транзакций для осуществления рефанда или пересчета каких-то метрик и бухгалтерии. Бизнесс- логика это не только «получил от пользователя данные - обработал - сохранил» Это ещё и «получил данные - выгреб из базы другие - логически обработал - и сохранил результат» Так вот во втором случае - хорошо бы выгребать список объектов.

А зачем тебе переводы в бизнес логике?

Я выше привёл другой пример с транзакциями.

Опиши что за операцию ты сделать хочешь

В целом я хочу понять каким образом мне из базы вытащить объект или список объектов (аггрегатов) с его зависимостями , чтобы потом с ним работать и можно ли это сделать без сотни запросов в базу? DDD же подразумевает то, что может быть ситуация, когра у тебя есть какая-то коллекция аггрегатов, которую нужно обработать какой-то бизнесс-логикой. Если нужен конкретный пример то например есть список подписок (агрегатов) на какой-то условный youtube-premium и у этих подписок есть транзакции (успешные/неуспешные) и каждая из успешных транзакция продлевает подписку на месяц. И потом начинается всякая-разная бизнес-слогика связанная с тем, что нужно продлевать подписку какие-то транзакции не прошли и нужно подписку отменить. где-то пользователь пользовался примиумом и решил перейти на премиум+, но переход произошел неудачно и нужно откатить изменения на старый тариф с восстановлением дат транзакций и т.д. и этой логики может быть очень много... И все это упирается в то, что тебе из базы нужно получать массив ОБЪЕКТОВ аггрегатов и работать с ними. И я пока не вижу другого пути как получать список Root-классов аггрегата, а потом отдельными запросами получать их зависимости. Или делать RAWSQL джойны и потом маппить полученный массив колонок ручками на класс-аггрегата.

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

Хорошо, другой пример. Есть у тебя гуглдрайв и в нем есть папки (Foldes) и файлы (Files). и вот нужно тебе расшарить папку на другого юзера. Т.е. тебе нужно получить список файлов (Files) в этой папке и и каждому файлу добавить пользователя $file->addUser($user, $previleges) т.е файлы тебе нужно достать объектами. И в случае с DDD ты можешь сделать $folder->addUser($user, $previleges, $recursive = true) и юзер добавится и к папке и ко всем файлам (и даже подпапкам) внутри нее. Можно конечно сказать "пшло нна это ваше ооп" и сделать foreach { INSERT INTO file_users ($file_id, $user_id, {"access": "viewer"}) } но поддерживать такой код будет очень прикольно)))

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

Не джойны множественные, а запросы множественные (которые я хочу минимизировать например джойнами) Ну как минимум тебе нужно как-то добыть все файлы в указанной папке с рекурсией.

У тебя база падает от нагрузки, или откуда проблема взялась?

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

Надо глубже понимать что именно ты пытаешься сделать, на конкретном примере. Каждому кейсу своё решение, абстрактного решения тут нет. Но звучит, что ты что-то не так делаешь

Хорошо. Т.е. если в случае с с постами и переводами мне нужно получить список всех постов на русском языке (например для обучения поиска), то нужно просто взять в PostService запилить метод, который через entityManager сделает сырой SQL запрос с джойном и вернет массив постов с русским контентом? Правильно?

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

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

А потом работать с массивами данных после чтения?