Структура проекта с использованием модели на hibernate

Hibernate

best practice его использования

Его не использовать, серьезно. Если по пунктам:

1. Вролне адекватно. 2. Адекватно, генераторы нафиг. 3. liquibase

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

Ага

Hibernate - зло.
Без него намного проще и очевиднее.

Без него намного проще и очевиднее.

При использовании jdbcTemplate с целью упрощения я постоянно приходил к чему-то на подобие хибера.

ORMLite лучше возьми, если нет хитросплетений в схеме. Очень прозрачно мапит, предсказуем в 99% случаев.

К чему именно?
К какому-нибудь классу MyClassDAO в котором набор методов типа CRUD'а?
Если да, то такие свои даошки куда удобнее и гибче, нежели этот монстр хибер, который хз что делает внутри себя.

Не, конечно, каждому свое, но у нас от хибера одни только проблемы: периодически возникает возня с транзакциями (кто-нибудь обязательно ошибется с ними), то наши DBA'щики ругаются, что хибер гигантские и неэффективные запросы генерит и тп.

Насколько адекватной выглядит идея спихнуть всю модель в отдельный проект?

На самом деел не очень. Вытащил ты объект хибернейтом в первом проекте - как ты его перетащишь в jax-ws сервис? Как быть с тем, что он managed? Ну или поясни идею с проектами поподробнее, если я не так понял.

Насколько неадекватно выглядит идея наваять схему данных «руками» и не доверять генератору хибера?

Предсказуемость повысится, портируемость - нет. Придётся вручную править при любом изменении классов-entity. Если проект быстро развивается и БД меняется - нет смысла, когда уже более-менее сформирован - можно, для оптимизации.

с остальным не сталкивался

Вытащил ты объект хибернейтом в первом проекте - как ты его перетащишь в jax-ws сервис?

Я и не планировал, что объекты будут свободно гулять между сервисами. Основная задача, которую я хочу этим решить - так сказать, вынести «контракт» (в нашем случае - классы модели) в отдельный проект.

Насколько адекватной выглядит идея спихнуть всю модель в отдельный проект? При этом этой моделью будут пользоваться несколько jax-rs/ws веб-сервисов;

А какие ещё есть варианты? Не копипастить же. Нормальная идея.

Насколько неадекватно выглядит идея наваять схему данных «руками» и не доверять генератору хибера?

Очень правильная идея. Генератор хибера только для быстрых прототипов годится. Не говоря уже о миграциях.

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

Что модно использовать с хибером для миграции схемы данных?

Что угодно. Liquibase думаю вполне подойдёт, тем более ты его знаешь.

Делают entity, которые конвертируются в доменные модели. Для веб-сервисов пишутся отдельные дто, в которые потом конвертируются эти доменные модели. Если использовать clean architecture, то бизнес логику держим в core, core дергает методы dao адаптера, передавая туда доменные модели, dao адаптер конвертирует доменные модели в entity и вызывает уже само dao, передавая в его методы entity.