Блог

При создании объекта с помощью помощника Jhipster он спрашивает

 ? Do you want to use separate service class for your business logic? (Use arrow keys)
> No, the REST controller should use the repository directly
  Yes, generate a separate service class
  Yes, generate a separate service interface and implementation
  

В каком случае я должен использовать какой вариант?

Каковы преимущества и недостатки каждого решения?

Возможно ли легко изменить архитектуру, как только все настроено?

ИМХО, это зависит от того, насколько сложным будет ваше приложение и как долго вы планируете его поддерживать.

Если ваша модель домена довольно проста, а ваши контроллеры REST представляют собой простые операции CRUD без сложного сопоставления, вы можете обойтись без использования отдельного сервисного уровня.

Если ваша модель домена или взаимодействия становятся более сложными, вам может потребоваться «Разделение задач»: ваши классы контроллеров должны просто сопоставлять вызовы REST из / в правильные DTO для REST API, а бизнес-логика и координация между различными объектами должны осуществляться в классе обслуживания, который не имеет ничего общего с REST API. В долгосрочной перспективе это упрощает внесение изменений в REST API отдельно от изменений в бизнес-логике.

Несколько сообщений в блоге для чтения:

https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-way/

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Затем о решении использовать интерфейсы или нет. Основные преимущества использования интерфейсов раньше заключались в том, что это позволяло проводить лучшее тестирование и избегать слишком тесного соединения модулей. Но с 2010 года было много дискуссий о том, стоит ли это накладных расходов. Возможно, начните читать обсуждение под оригинальным сообщением Адама Бьена:

https://www.adam-bien.com/roller/abien/entry/service_s_new_serviceimpl_why