Хз, нужен или нет, мне кажется, все равно оправдан очень часто. Но точно было бы проще и жесткие компромиссы встречались бы реже.

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

Но вот есть в планировании ядро, где десяток сущностей связаны очень плотно и это правильно. И нужно этот сгусток вертеть то так, то эдак, то пакетами, то поштучно. Хорошо хоть, что нагрузка почти нулевая. Но сложность моделей и разнообразие выборок оправдывает ORM просто на раз. После этого в букмекерские модели смотришь - ну просто лафа! Ничего ни с чем не связано и вчерашние данные - уже практически архив.

Так это может быть сервис бизнес-логики, вообще без хранилища своего.
Такие часто вылезают, да.

Ну, мне вот сложно все еще сформулировать понимание, когда ORM нужен, когда нет (и какой ORM, там много вариантов).
Пока в реальных проектах, которые я видел - он скорее мешает.

Но в поддержке плохо порезанного легаси - наверно нужен (с генерацией по базе)

Э, а ты в букмекерских данных до лимитов уже дошел? И доходности компании?
Там как раз вчерашние данные очень даже нужны )

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

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

Я, правда, букмекерский софт писал уже давно, но зато для лидера рынка )

(И вообще скорее для англичан)

(Английский букмекинг вообще сильно отличался от нашего. Свадьбы и дети на ипподромах и собачьих бегах (и хороший ресторан) - как норма)

Я думаю, еще сильно зависит от того, как организован сервис. Если, к примеру, все варианты чтения загнаны в Repository, то ORM может быть менее эффективен - потому что все равно много boilerplate-кода. Если же ты разрешаешь доменные запросы формулировать не в виде жесткого API, а в виде гибкого query object в read model, в application layer, или в доменных сервисах, то выгода от orm растет - но тут надо понимать, конечно, как отмечал @WatchTh15 , что можешь обменять скорость разработки на сопровождаемость.

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

Ну, я вот очень не люблю rich model и сторонник anemic model и явно выделенного Dao layer.
На длинных дистанциях оно упрощает жизнь

Ну, это да.
Хотя "последняя штука на складе" там тоже есть - "работа на грани лимитов по событию с непрерывным хэджированием"

Но если ты для РФ рисуешь, то у нас такого обычно нет )

Угу, наверное. Туда еще не добрался.

Мне кажется, что затронули живую тему. @dphil @IgorBespalchuk не желаете сделать что-то вроде модерируемой панельной дискуссии с публикацией по итогу?

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