пара - не 100

это вполне можно сделать и в DAO

Да где он сложный-то? Гораздо проще того же котлина. И, главное, почти никакой экосистемы учить не нужно )

да можно лексер и парсер бизоновский покурить от посгреса. внушает.

Разработчик уровня senior должен знать,  code monkey не обязательно. Там вся теория на несколько страниц текста или тоненькую методичку,  если воду не лить. Потом закрепить на практике и алга! ) иначе боль, сейчас много приходит разрабов, которые про фулскан, индексы и реляционную теорию не слышали. А как там ORM разложит - "и так сойдет". Если компания себе неможет штат узкопрофильными спецами раздувать, то сосем все плохо

Самая большая проблема с этим в том что эти выделенные эксперты должны будут контролировать работу разработчиков,
чтобы очередной "мелкий багфикс" не положил базы на проме.
Контроль = bottleneck в организационном аспекте

Решение вижу только в развитии компетенций разработчиков.
И, конечно, эскизное проектирование основных сущностей системы должен сделать архитектор, либо ведущий разработчик. А детали уже отдавать в реализацию линейным разработчикам.

а вот тут уже как раз идейно философское противоречие между вселенными ооп и QL , не получается и там и там гуру в пром масштабах готовить, mind shift

контроль - будет ботл неком если его криво организовать

это риск старта продукта

а не катастрофы в проме через пару лет

хотя , я не топлю за ОРМ, я вполне толерантен к продуктам чисто на PL SQL

А как же инварианты конкретных сущностей?

Лексер там сложный, вон Оракл 20 лет не могла справиться.
Но это не проблема программиста, он пользуется результатом )

Имеете в виду схему БД?

Так это про инварианты самих сущностей. Но у тебя доменный объект сам свою целостность контролирует, это не связано с бизнес-логикой их взаимодействия. Ну и транзакции помогают )

Просто для меня бизнес-логика это не только взаимосвязи между сущностями, но и их инварианты. Обычно в системах с анемичной моделью соблюдение инвариантов перекладывается на сервисной слой. У вас не так?

Что для тебя инварианты, я плохо понимаю вопрос.

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

Ну да, у объекта нет просто setter, есть только бизнес-специфичные методы, переводящие его из одного состояния в другое.
Но при этом варианты типа "три созаемщика" или "два, но один богатый" - это не про саму заявку (и вообще не ее инвариант), это параметры бизнес-процесса (и обычно зависят от кучи настроек), им нечего делать в собственно объекте заявки.

То есть есть элементы домена, а есть процессы работы с этими элементами.
(У нас даже, фактически, про элементы домена думает продакт, а про процессы - проджект менеджер)