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

Гипотетически я могу вообще врайт писать на sql и много что не будет знать)

инстаграм вообще отличный пример проекта где нахер не нужны ОРМ-ы и "сущности"

почему - потому что там колаборации нет. Все работают исключительно со своими ресурсами. Нет пересечений никаких. Делай как хочешь все будет работать и все будет норм скейлиться

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

инстаграм же зарабатывает на том что продает инфу кому что нравится а не на том что кто-то кому-то посты лайкает

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

Грубо говоря, всякие штуки типа коллекций, особенно которые связаны только связью, лучше сразу выносить в "сервисы" так как это дешевле по работе с БД?

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

и в целом структура твоих "бизнес сущностей" в 90% ситуаций диктуется требованиями UI, что уже говорит что хваленая разделение ответственности и все эти "слои" которые всем так нравятся пошли по пизде

ORM - это в первую очередь сохранение состояния, а не прослойка в базу
О чем речь то?

@fes0r благодарю, теперь понятнее

Вопиющее мракобесие

ORM это инструмент решения задачи мэппинга in-memory структур (где есть референсы) на модель данных где референсов нет. Все остальное - это то что ты придумал поверх этого.

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

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

Через пяток лет серверлес будет обыденностью потому привыкайте к тому что вопрос локальности данных будет стоять куда более остро

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

агрегат который знает про все ссылки на свете?

Только про свои. Есть "услуга", а есть "ссылки на ютуб" типа профайла этой услуги

так, ДДД говорит спросить у бизнеса что делать.

мол смотри... как убедиться что в базе будет только уникальные ссылки - повесить юник констрейнт. Так? то есть если будет дубль то по пизде пойдет. Дальше вопрос - откуда дубли берутся? с этим ты идешь к бизнесу и выясняешь. Может быть там просто контент менеджер из спредшита руками заполняет (может тогда импорт сделать проще?) может быть еще чего....

Не зная бизнес сторону вопроса ты будешь искать технические решения технических проблем. А ДДД оно не про технические проблемы, оно про buisness domain : )

interface ArticleLikeServiceInterface
{
   public function hasLike(Article $article, UserInterface $user): bool;
   public function like(Article $article, UserInterface $user): void;
   public function unlike(Article $article, UserInterface $user): void;
}

и всё - задача решена - остальное не важно

Нет, констрейнты в БД не решат задачу, так как униклаьность в рамках одной сущности.