Как лучше всего организовать аутентификацию и авторизацию в микросервисах, где используется внешний oauth сервер и нужно не только отдавать ресурсы залогиненым юзерам, но и устанавливать соединение с вебсокетом? Все запросы идут через Spring cloud gateway
И надо чтобы не приходилось делать это каждый раз после перезапуска сервисов

JWT

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

Считать в файл или в память и отправить

Можно ли контроллеры наследовать от интерфейсов, в которых есть методы помеченные как @RequestMapping?

Нужно ли перепомечать их в наследуемом классе?

не видел такого

Этот вопрос связан с реализацией feign клиента
Он сам по себе интерфейс, и если от него наследоваться, то получается наверняка стабильная реализация и контроллера и клиента

у меня несколько вопросов, кто может помогите (можете написать, если в чем-то ошибаюсь):
1) можно ли держать простую логику в entity? на подобии таких методов: isNew, isOngoing, isRturned, externalDays
2) или лучше, всю логику держать в domain service - "MovieRentalService"
3) или стоит держать только сложную в отдельном сервисе, ибо мне кажется что простую логику на подобии такой isNew, isOngoing, isRturned, externalDays, можно держать и в entity.
4) у меня два класса "MovieRental и MovieRentalService",
где у MovieRentalService есть след. методы: calculatePrice, calculateLateCharge и т.д.,
работать это будет так movieRentalService.calculatePrice(movieRental), где внутри метода calculatePrice, будет сеттиться цена фильма для объекта movieRental.
на подобии такого думаю сделать - https://github.com/adityasatrio/domainModel/blob/master/DomainModelPattern/src/anemic/domain/service/OrderService.java, нормальное ли это решение.
5) нормально ли что у класса есть все сеттеры? так как до этого у меня были только самые необходимые setters,
так как внутри MovieRental был builder, внутри которого и происходили все расчеты, однако это не совсем удобно, так как объект становился immutable, поэтому я и начал смотреть в сторону отдельного сервиса, который и будет производить некоторые операции над моим объектом, но тогда мне придется добавить все setters-ы к моему классу MovieRental.

@Flassie можешь посмотреть, может сможешь подсказать пожалуйста

если не сильно занят

1) встречал такое, но не знаю насколько это норм. Как по мне - вполне себе

2) хз. Как по мне первый вариант лучше, но опять же - натыкался, но правильность не знаю

3) сложную логику точно в сервисы

4) странный подход, но думаю вполне норм

5) думал на эту тему. Есть автогенерируемые данные, типа id. Вот их менять нельзя. Все остальное, что меняется, вполне может иметь сеттер, как по мне

4) это anemic domain model - когда у тебя вместо того чтоб все пихать в один Entity, ты разбиваешь на сервисы,
до этого был builder - знаешь как builder pattern, в конце запукал build и он мне все считал и генерировал, но из-за этого объект получилося immutable и я страдал.

зацыклен на правильности кода =(

спасибо за ответы

Да, я понимаю

Anemic Domain Model подразумевает под собой отсутствие или МИНИМАЛЬНОЕ количество бизнес логики. То есть добавить туда что-то простое можно

Касательно билдера, имхо, паттерн хорош, но не для Entity из jpa

понятно

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

Можно запускать конкретные тесты
Но вроде как или все, или один, или класс отвечающий за тесты