ClasificaciónDeEvans
Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer
En su excelente libro Domain Driven Development, Eric Evans hace una clasificación de los diferentes tipos de objetos de dominio que es probable que te encuentres:
1. Entidad (Entity): Los objetos que tienen una identidad distinta que traspasa el tiempo y representaciones diferentes. También los habrás oído llamar " objetos referencia".
2. Objeto Valor (Value object): Lo importante de estos objetos es únicamente la combinación de sus atributos. Dos objetos valor con los mismos valores para todos sus atributos son considerados iguales. También describo objetos valor en P de EAA.
3. Servicio (Service): Una operación independiente (standalone) dentro del contexto de su dominio. Un Objeto Servicio recoge uno o varios servicios en un objeto. Típicamente se tendrá sólo una instancia de cada tipo de objeto servicio dentro de tu contexto de ejecución.
Esta clasificación encaja bien con mi experiencia, de lo que se necesita en modelos de dominio. El problema es que el trío es difícil de definir con precisión, son de los de la categoría " los reconozco cuando los veo".
Algunos ejemplos pueden ayudar. Las entidades son generalmente cosas grandes como el Cliente, el Barco, el Acuerdo de Alquiler. Los Objetos de Valor son por lo general pequeñas cosas como la Fecha, el Dinero, la Sentencia de Base de datos. Los servicios son por lo general accesos a recursos externos como la Conexión de Base de datos, la Puerta de Enlace de Mensajería, el Repositorio, la Fábrica de Productos.
Una división clara entre entidades y valores es que los valores sobrescriben el método de igualdad (y consecuentemente el método hashCode) mientras las entidades por lo general no lo hacen. Esto es porque por lo general no se quiere tener más que un objeto representando la misma entidad conceptual dentro de tu contexto de procesamiento, sin embargo no nos preocupamos por múltiples objetos "5.0". Los valores pueden ser primitivos (en los lenguajes que hacen distinción) o tienen el apoyo de un lenguaje especial (como se hace en .NET) pero no es obligatorio. Una regla importante a seguir es que los objetos valor deberían ser inmutables (de otra manera se provocan todo tipo de problemas de errores de solapamiento).Para cambiar un valor (como mi altura) no se cambia el objeto de altura, sino que se sustituye por nuevo uno.
Los objetos servicio son a menudo implementados usando variables globales, campos de la clase (monoestados en la terminología de Robert Martin) o "singletons". En realidad normalmente se singulariza, con lo que sólo se tiene uno de ellos, pero la forma de hacer esto es más variado. Por lo general la singularidad es dentro de un contexto de procesamiento - es decir, uno por hilo en un entorno multihilo. En cualquier caso se debería uno asegurar de que su mecanismo de implementación está escondido para los otros objetos de dominio de forma que se pueda cambiar fácilmente. Eric declara en su libro que los servicios deberían ser sin estado, aunque hemos hablado de esto y él no sigue creyendo que sea necesario - de todos modos es preferible que lo sean.
Uno de los problemas con este área es que esta terminología, aunque evocadora, está terriblemente desordenada con otras ideas. La entidad es a menudo usada para representar una tabla de base de datos o un objeto que corresponde a una tabla de base de datos. El servicio tiene la Arquitectura Orientada a Servicios (SOA) al completo, así como las capas de servicio en la arquitectura de aplicación. Así que si uso estos términos tengo que aclarar que los uso dentro del contexto de Modelos de Dominio y según su significado en el libro de Eric. Así que sé cauteloso al asumir que la gente está usando estas palabras de la misma forma - están muy sobrecargadas. Tristemente no hay mucha alternativa.
