Здравствуйте, ·, Вы писали:

·>Да всякое бывает. По ddl можно генерить код на ЯП, чтобы строить те же sql запросы с type-safety, без всякого ОО.

Можно. А вот если ты те модели выставишь в публичное API — скорее всего будет кака.

·>Ты, видимо, об ORM говоришь, неясно причём тут оно.

Давай я тебе на простом примере продемонстрирую. Возьмем REST API и метод получения списка сущностей. Для одного типа сущностей мы, как правило, имеем один uri (часто это явно зафиксировано в гайдлайнах), и, как следствие, один метод контроллера сервиса. Если при этом мы имеем несколько разных юзкейсов, то сумма этих юзкейсов порождает набор фильтров в параметрах на все случаи жизни.
Далее из этого автоматически генерируется OpenAPI spec (тут все еще ОК, потому что это все еще модель REST), а потом по ней клиент. И вот тут нам генератор породит и на клиенте метод-всемогутор, который, конечно, обладает максимальной гибкостью, но при этом еще и максимально неудобен, потому что нет ни одного юзкейса где нужны были бы все фильтры. И во вручную написанном клиенте вместо одного метода-всемогутера было бы N методов под каждый юзкейс.
Аналогичная ситуация и с классами-DTO.
Теоретически можно было бы обвесить метод контроллера метой, которая бы описывала юзкейсы, и которая передавалась бы в составе OpenAPI spec, а генератор эту мету доставал бы и генерил удобного клиента, но на практике я такого генератора не видел даже близко.
Аналогичная ситуация и с ORM. Вся идея с тем, что мы ORM кормим POCO, а потом эти же POCO выставляем в публичный API работает только на демках. Еще хуже работает когда эти POCO не вручную пишутся, а генерируются из схемы БД. Поэтому в реальности в лучшем случае только сабсет модели общий для всей цепочки, а полная модель у ORM, REST и клиента у каждого своя.
Это я еще не вспоминаю про те же ad-hoc типы в ORM, которых в Java нет, но там где они есть это очень мощная штука.