Ответ 1
Здесь общий подход:
- Сначала мы создали пустой проект со всеми стандартными JHipster стек. СУБД используется Postgres. Мы изложили основную структуру данных с помощью инструмента генерации сущности jhipster, создавая наиболее важные отношения и т.д. Мы также определили основные пользовательские роли и разрешения в стандартных вариантах JHipster. На этом этапе мы не платили очень большое внимание к деталям, таким как сложные уникальные ограничения, бизнес-ограничения, управление пользователями, обработка ошибок JPA и презентация и т.д. Просто создал своего рода основу для начала. Страницы CRUD являются стандартными.
- Мы представили некоторую бизнес-логику, специфичную для домена. Была выполнена основная настройка интерфейса: брендинг, стили, некоторые пользовательские представления (по-прежнему используются классы начальной загрузки) и т.д. Рамка, созданная Jhipster, была сохранена на месте, но расширена. Мы немного изменили логику авторизации на обоих бэкэнд и frontend, он основан на токенах с определенной проверкой маркера правила. Была введена удобная обработка ошибок, позволяющая пользователю понять, какие бизнес-ограничения проявляются в различных условиях. Мы начали писать более сложные модульные тесты для удовлетворения недавно реализованной бизнес-логики. Объекты в основном (~ 80%) создаются вручную на данном этапе, потому что мы привыкли к структуре данных, предлагаемой JHipster, и у нас было слишком много настроек в контроллерах CRUD REST, страницах и тестах, охватывающих все это. Списки изменений Liquibase были созданы с помощью Liquibase: diff и отредактированы вручную. Мы не добавляем такие объекты в папку .jhipster.
- Из-за того, что требования к дизайну интерфейса стали высокими и строгими, было решено ввести отдельный интерфейс для взаимодействия с конечным пользователем. Он частично разделяет интерфейсы REST с интерфейсом, созданным с помощью jhipster, но абсолютно независим с точки зрения структуры проекта. Мы решили использовать Angular для нового слоя frontend. Фактически, это подпапка с отдельными index.html, bower.json, Gruntfile.js и т.д. В то же время мы продолжали совершенствовать бизнес-логику, улучшать структуру db, увеличивать охват кода, вводить новые пользовательские роли и т.д.
- ...
Итак, у нас есть слегка настроенный "старый" интерфейс JHipster для администрирования и управления данными. И независимый "новый" интерфейс с индивидуальным дизайном для работы с конечными пользователями. Обратите внимание:: возможно сохранить оригинальный интерфейс, настроить его до определенного предела и сохранить возможность генерации объектов, и он хорошо работал в нашем проекте, насколько это было оправдано.
Некоторые примечания:
- Компонентные версии в pom.xml постоянно обновлялись вручную;
- Зависимости Maven были добавлены вручную в pom.xml;
- Зависимости JS были добавлены вручную в index.html/bower.json/app.js;
- Если у вас есть сложные скрипты с интерфейсом, обработка JS uglification для профиля производства может быть сложной:
- Еще одна сложная задача - сохранить скрипты Liquibase для обеих СУБД, используемых spring -boot и H2, которые используются для тестов;
- Вероятно, у вас возникнут некоторые проблемы с настройкой конфигурации в зависимости от конкретной логики домена для вашего проекта.
Надеюсь, это поможет.