Каков путь наименьшего зла при работе с полиморфизмом и наследованием типов сущностей в сервис-ориентированной архитектуре?

Принцип SOA (насколько я понимаю) состоит в том, чтобы иметь классы сущностей в виде простых конструкций данных, в которых отсутствует какая-либо бизнес-логика. Вся бизнес-логика содержится в узко ограниченных, слабосвязанных сервисах. Это означает, что реализации сервиса настолько малы, насколько это возможно, что способствует слабой связи, и означает, что сущности избегают необходимости знать окаждый поведение, которое система может выполнять на них.

Из-за довольно странного решения Java использоватьобъявленный тип при решении, какой перегруженный метод использоватьлюбое полиморфное поведение в реализациях службы вместо этого заменяется серией условной проверкиobject.getClass() или используяinstanceof, Это кажется довольно отсталым в OOPL.

Является ли использование условных обозначений принятой нормой в SOA? Следует ли отказаться от наследования в субъектах?

ОБНОВИТЬ

Я определенно имею в виду перегрузку, а не переопределение.

Я определяю SOA как означающее, что поведение системы группируется по сценариям использования в интерфейсы, а затем логика для них, как правило, реализуется в одном классе на интерфейс. Как таковой класс сущности (скажем,Product) становится не более чем POJO с геттерами и сеттерами. Он абсолютно не должен содержать какой-либо бизнес-логики, связанной с сервисом, потому что тогда вы вводите одну точку привязки, посредством которой класс сущности должен знать обо всех бизнес-процессах, которые могут когда-либо работать на нем, полностью отрицая цель слабо связанной SOA ,

Таким образом, поскольку не следует встраивать поведение, специфичное для бизнес-процессов, в класс сущностей, нельзя использовать полиморфизм с этими классами сущностей - нет поведения, которое можно переопределить.

ОБНОВЛЕНИЕ 2

Вышеупомянутое поведение более просто объясняется какперегруженный путь выбран ввремя компиляцииипереопределены путь ввремя выполнения.

Было бы плохой практикой иметь подкласс вашей реализации сервиса для каждого подтипа класса модели домена, на который он действует, так как же люди справляются с проблемой перегрузки во время компиляции?