@Query(value = "select d.id,d.name,d.breed,d.origin from Dog d",nativeQuery = true)
 List<Dog> findALL();

 @Query(value = "select u.name, u.surname from get_values() u", nativeQuery = true)
 List<PersonName> getPersonFullName();

Раз уж обмазался функциями - добавь и вьюху и читай из нее )

Обычный класс, не сущность с полями имя и фамилия

с проекцией может сработать

Сейчас инициирую проект, нужно сразу заложить возможность разработки бизнес-модулей несколькими  командами. Микросервисы нет возможности использовать, т.к. приложение будут разворачиваться в инфраструктурах многих заказчиков и должно быть легким в эксплуатации. Как думаете норм тема организовать бизнес-модули в виде спринг бут стратеров? В свою очередь каждый из этих бизнес-модулей будем многомодульным проектом мавен/градл поставляющим jar стартера, а объединяющее приложение обычным проектом на спринг буте

Стартеры как многомодульный проект звучит кхмм так себе

Звучит на первый взгляд неплохо, но могут быть проблемы с запуском, если будут зависимости стартеров друг от друга в части порядка запуска.
Есть ещё вот такая штука: https://github.com/odrotbohm/moduliths даёт улучшенную инкапсуляцию, которую удобнее использовать, чем модули

почему?

спасибо, смотрю

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

как организовать при этом liquibase, хороший вопрос )

А что в самом главном проекте будет где эти стартеры использоватся будут ? Какая-то логика будет завязанная на эти подмодули или как ?

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

+ если используется хибернейт или какая другая jpa имплементация - то если я правильно помню была проблема 1 таблицу на разные энтити мапить

Так просто надо держать всё в одной репе, просто аккуратно следить за зависимостями. В частности, либа, которую я скидывал в этом очень помогает

звучит как commons-repo.jar  =)

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

С точки зрения скороти сборки - надо просто брать gradle или bazel и проблем не будет. Короче, я большой адвокат монорепы 😁

значит будет борьба команд за доминирования этого коммонс репо либы - и тут я уверен будут проблемы

я бы на самом деле тоже предложил бы в одном репо все делать

Ну, если команд много, а проект один, наверное, будет какой-то совещательный архитекурный орган