Жизнь заставляет провести выделение DAO уровня в отдельный артефакт, для простоты миграции на другое хранилище данных.
Обнаружил, что модели (entity) зачастую имеют много навешанных аннотаций, которые в новом хранилище и его ORM не применимы.
Так как entity используются на сервисном уровне, который остается общим, соответственно имеется мысль выделить у entity интерфейсы и их использовать на сервисном уровне.
Является ли это нормальной реализацией или все-таки это не соответствует представлениям о прекрасном?
Жизнь заставляет провести выделение DAO уровня в отдельный артефакт
Ну так и выделяйте. Потом, когда мигрируете полностью, всё равно небольшой рефакторинг придётся делать. Заодно и это поправите. А там глядишь и ситуация другая будет.
Хотелось бы выделить так, чтобы по-минимому затрагивать сервисный уровень, а идеально вообще его не трогать. Т.е. мысль была следующая — я выделяю интерфейсы у entity классов и на сервисном уровне работаю с интерфейсами, а имплеменчу их в DAO артефакте как требуется для конкретного ORM'а. Но на деле оказалось, что на сервисном уровне объекты не просто читаются, а также и создаются (entity), и в последствие передаются в DAO уровень для сохранения. Поэтому интерфейсы тут не получаются.
Отсюда я буду делать следующим образом: я создам артефакт dao-api, который будет содержать интерфейсы DAO без имплементации, pojo классы которые будут приниматься и отдаваться DAO.
На сервисном уровне будет идти работа с ними.
А в DAO имплементации, которая будет в другом артефакте (dao-impl), будут имплеменчены интерфейсы DAO классов, и трансформеры, перегоняющие туда-сюда pojo в entity.
Да, добавляются ненужные сущности и конвертация, но получается неплохая абстракция и хорошая независимость от реализации DAO уровня.
Не совсем понял вопроса, вы хотите отказаться от DAO?
Если так, то например в spring roo так и сделали, все DAO медоты статичны и принадлежат классу entity.
Нет, я не отказываюсь от DAO. Я меняю имплеменатцию DAO уровня с одной на другую, которая использует другую технологию. И хочется сделать это так, чтобы не переписывать все приложение. Благо уровень уже есть, надо подумать как его хорошо абстрагировать от остального приложения и выделить его в отдельную библиотеку, чтобы потом эту библиотеку подменить.