Стоит ли дублировать модель сущности?

Почему бы вам просто не добавить на свои интерфейсы Course и Lessonextends Payable? Таким образом, у вас будут ваши сущности, которые будут Payable. Хотя, что касается дизайна, я настоятельно рекомендую не использовать такое решение, поскольку для сущностей лучше не иметь интеллекта в своем коде.

В чем именно проблема? Почему бы вам просто не позволить Course и Lesson реализовать интерфейс Payable?

@HBo, Course и Lesson - это классы сущностей. если я реализую интерфейс Payable, они будут содержать методы из интерфейса Payable. Правильно ли содержать бизнес-методы в классах сущностей?

@ElvinAliyev вроде как в точку, да. Но вам действительно стоит создать пример, показывающий нам, что вы сделали, что не так и что вы пытались исправить. Кроме этого, это просто догадка за догадкой ...

@DamCx не могли бы вы объяснить, почему у сущностей не должно быть интеллекта в своем коде? Желательно со ссылкой на признанную методологию. Те, кого я знаю (особенно DDD), говорят прямо противоположное

@crizzis DDD - это особый способ разработки кода и объектов. В большинстве случаев сущности JPA генерируются, поэтому вы не хотите иметь в них интеллекта, поэтому вы уверены, что ничего не пропустите и не сломаете свой код.

@DamCx «В большинстве случаев сущности JPA генерируются» звучит довольно анекдотично, и если бы я предоставил собственное анекдотическое свидетельство, это указывало бы на вывод, что в большинстве случаев сущности генерируются нет. Все, что я хотел отметить, это то, что ваш комментарий звучал так, будто в JPA существует техническое ограничение или всеобщий консенсус в отрасли, что сущности не должны содержать логику, ни то, ни другое на самом деле не так.