Уффф.. чтобы это был серьезный разговор - надо примеры тащить. А из рабочего кода их не притащишь....

Ну lorem ipsum... Не?

Мне кажется, все это уже 100 раз обговорено и описано в интернете..

А где выводы можно почитать без  агитации?

"Почему вам не нужен  ORM". "Почему вам не нужен Repository  если есть ORM"...

Хм… ну я бы предпочёл честный CDC, а потом его обрабатывать нормальным ETL…

А вот нормальный словарь данных и метаданных я бы хотел иметь безотносительно других инструментов

Чтобы прийти к реально обоснованному выводу, это нужно действительно запрототипировать ряд характерных задач из нескольких доменов, оценить кол-во таких задач, рассмотреть варианты с/без orm, померять объемы boilerplate'а, и все равно каждый останется при своем убеждении, сформированном из частного опыта....

Тут не с чем спорить :(

Ну, нормальный CDC все хотят )

"Доказанная эффективность ORM", ага)))
Двойное слепое тестирование, как с лекарствами
Типа три контрольных группы, одна с ORM, другая без, третья - с плацебо)
+ описание побочек и противопоказаний

Пока тестирование на POC не пройдет, допускать исследований на MVP и не дай боже на реальных проектах запрещено

вообще обобщения на тему ORM вредны и опасны ИМХО, очевидно что в ряде случаев продукт генерации гибернейта может сильно утопить пром без каких либо шансов на решение проблемы, так же очевидно что ООП не реализуем красиво в системе коордскинат реляционной субд, какого то рабочего решения в объектных базах тоже нет. Действительно работа в сыром сиквеле может спасти ситуацию, но практике когда продукт перевалит за 2mln LOC это может существенно осложнить жизнь в части аудитов безопасности, статичеческих анализаторов да и вообще просто код ревью. В моей практике был случай когда продукт и компания покупался могучей американской конторой был забанен из за сырого сиквела, перевести на айбатис было проще и целесообразней рефакторинга сиквела.

Для себя я так сформулировал. ORM хорошо подойдет для "database-driven" систем с простой или вовсе отсутствующей бизнес-логикой и возможно развесистой моделью данных. В таких системах сущности - это просто представление таблиц в коде, а вся имеющаяся логика, если имеется, находится в сервисном слое. В "domain-driven" системах со сложной бизнес-логикой и богатой моделью, где важно изолировать модель от слоя хранения данных, ORM будет только мешать. Лучший ORM это тот, который не протекает.

А какие проблемы с богатой моделью? У меня прямо противоположный опыт :)

класс Payment на 20к строк

проблем масса, включая и невозможность корректного двустороннего действия.
Publisher.sendTo(subscriber) или Subscriber.receiveFrom(publisher) ?

Кстати, стоило упомянуть, что мой опыт связан с системами со средней или сложной бизнес-логикой. В системах без логики анемичная модель вполне ОК. Многое зависит от профиля системы

В моем случае такое количество строк в одном классе вызвало бы вопросы к проектированию. Я видел и обратную сторону, 20к строк в условном PaymentService

Я как раз про системы со сложной логикой )