тут я немного опечатался - имел ввиду CQS (Command query separation)
этот подход неоднократно встречал и использовал на разных проектах, из плюсов домен (а также сущности и репозитории/да и все остальное из тактических шаблонов ddd) максимально привязаны к предметной области (никаких generic репозиториев и прямого использования ORM в логике и т.п. мути), конкретная реализация репозиториев может быть разная, но если есть хороший ORM, который умеет из хранилища воссоздавать сложные агрегаты/сущности (не знаю как в Java мире - в .net EF core научился наконец-то творить чудеса просто), то можно внутри репозитория использовать ORM.
Ну и важно следить чтобы конкретный ORM не протёк в app layer. Я несколько раз сталкивался с полной заменой ORM в проекте, а также переходом на другие БД - uhe,грубо говоря раз в год подобного рода задачи возникают. И вот тут репозитории очень сильно помогают.
Ну и важно иметь хорошее покрытие тестами, без этого возникнут приколы что на новой версии ORM начал генериться другой SQL
А на счёт сложных запросов - для большинства сценариев пишутся query где хоть чистый sql запросы пиши (тоже дикий антипаттерн, в .net часто dapper используем)
Главный плюс ORM - его использование в разы сокращает время поставки продукта рынку, увеличивая качество и снижая стоимость, особенно на крупных проектах.
CQRS - в commands используем репозитории на основе orm для работы с доменными агрегатами/сущностями, в queries - пишем запросы любой сложности использую любую технологию доступа к БД.
тут я немного опечатался - имел ввиду CQS (Command query separation)
этот подход неоднократно встречал и использовал на разных проектах, из плюсов домен (а также сущности и репозитории/да и все остальное из тактических шаблонов ddd) максимально привязаны к предметной области (никаких generic репозиториев и прямого использования ORM в логике и т.п. мути), конкретная реализация репозиториев может быть разная, но если есть хороший ORM, который умеет из хранилища воссоздавать сложные агрегаты/сущности (не знаю как в Java мире - в .net EF core научился наконец-то творить чудеса просто), то можно внутри репозитория использовать ORM.
Ну и важно следить чтобы конкретный ORM не протёк в app layer. Я несколько раз сталкивался с полной заменой ORM в проекте, а также переходом на другие БД - uhe,грубо говоря раз в год подобного рода задачи возникают. И вот тут репозитории очень сильно помогают.
Ну и важно иметь хорошее покрытие тестами, без этого возникнут приколы что на новой версии ORM начал генериться другой SQL
А на счёт сложных запросов - для большинства сценариев пишутся query где хоть чистый sql запросы пиши (тоже дикий антипаттерн, в .net часто dapper используем)
Главный плюс ORM - его использование в разы сокращает время поставки продукта рынку, увеличивая качество и снижая стоимость, особенно на крупных проектах.
CQRS - в commands используем репозитории на основе orm для работы с доменными агрегатами/сущностями, в queries - пишем запросы любой сложности использую любую технологию доступа к БД.