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

у меня несколько вопросов, кто может помогите (можете написать, если в чем-то ошибаюсь):
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.

По-моему подход в п. 4 не очень хорош.
Сложная бизнес-логика в сервисах - это нормально. Но метод сервиса должен возвращать результат, а не записывать его внутрь переданного же объекта. Иначе получается, что до вызова данного метода на объекте, объект не полный. Этот объект могут принимать в качестве аргументов другие методы, которые никогда не знают, полный или не полный им объект передали (за этим обязан будет следить использующий эти методы программист - это очень хрупкое АПИ), но при этом их логика может рассчитывать на эти данные, либо каждый раз проверять их наличие и самим вызывать этот сеттер.
Как итог: запутанный код, когда вообще не понятно что от чего зависит, и для подстраховки всегда заполняется все.

Не все? Например?

сейчас два метода там у меня, скорей больше и не будет rentMovie и returnMovie, почему?

Если же этот calculateTotal будет вызываться ВСЕГДА при загрузке Order из БД (т.е. прямо в OrderService.findOrder() будет выполняться и других способов достать из БД ордер - не будет — тогда проблемы нет. У вас всегда в клиентский код попадает полный объект Order.