Cómo lidiar con el polimorfismo de Java en la arquitectura orientada a servicios

Cuál es el camino de menos maldad cuando se trata de polimorfismo y herencia de tipos de entidad en una arquitectura orientada a servicios?

Un principio de SOA (según tengo entendido) es tener clases de entidad como meras construcciones de datos, que carecen de lógica empresarial. Toda la lógica empresarial está contenida en servicios de alcance estrecho y acoplados libremente. Esto significa que las implementaciones de servicios son tan pequeñas como sea posible, lo que favorece el acoplamiento flojo, y significa que las entidades evitan tener que saber acerca decad comportamiento que el sistema puede realizar en ellos.

Debido a la decisión bastante desconcertante de Java de usar tipo declarado al decidir qué método sobrecargado utilizar, cualquier comportamiento polimórfico en las implementaciones de servicio se reemplaza con una serie de comprobaciones condicionalesobject.getClass() o usandoinstanceof. Esto parece bastante atrasado en una OOPL.

¿Es el uso de condicionales la norma aceptada en SOA? ¿Se debe abandonar la herencia en las entidades?

ACTUALIZA

Definitivamente quiero decir sobrecargar y no anular.

Defino SOA para significar que el comportamiento del sistema se agrupa por caso de uso en interfaces, y luego la lógica para estos se implementa en una clase por interfaz, generalmente. Como tal clase de entidad (digamosProduct) se convierte en nada más que un POJO con getters y setters. No debe contener ninguna lógica de negocios relacionada con un servicio, porque luego se introduce un punto focal de acoplamiento mediante el cual la clase de entidad necesita conocer todos los procesos de negocios que puedan operar en él, negando completamente el propósito de una SOA acoplada libremente .

e modo que, dado que no se debe incrustar el comportamiento específico del proceso empresarial en una clase de entidad, no se puede usar el polimorfismo con estas clases de entidad; no hay comportamiento que anular.

UPDATE 2

l comportamiento anterior se explica más simplemente como unsobrecargad ruta se elige entiempo de compilació, y un anulado ruta en tiempo de ejecución.

Sería una mala práctica tener una subclase de la implementación de su servicio para cada subtipo de la clase de modelo de dominio en el que está actuando, entonces, ¿cómo puede la gente sortear el problema de sobrecarga en tiempo de compilación?

Respuestas a la pregunta(5)

Su respuesta a la pregunta