25. Modelos anémicos y modelos expresivos: responsabilidades dentro del dominio

25.1 Introducción

Un modelo de dominio no debería ser solo una colección de datos. También debe expresar reglas, comportamiento y responsabilidades del negocio. Cuando los conceptos del dominio solo tienen atributos y todas las decisiones quedan en servicios externos, suele hablarse de modelo anémico.

En cambio, un modelo expresivo ubica parte importante del comportamiento dentro de los conceptos que tienen sentido para el dominio. Las entidades, objetos de valor, agregados y servicios de dominio colaboran para representar reglas y acciones con nombres cercanos al lenguaje del negocio.

25.2 Imagen conceptual de modelos anémicos y expresivos

25.3 Qué es un modelo anémico

Un modelo anémico es un modelo donde los objetos del dominio tienen datos, pero casi no tienen comportamiento. Las reglas importantes quedan dispersas en servicios, controladores, procedimientos, pantallas o consultas. Las entidades se vuelven estructuras pasivas que solo almacenan atributos.

Por ejemplo, si Turno solo tiene fecha, hora, paciente y estado, pero toda regla sobre reservar, cancelar, confirmar o atender está en un servicio genérico, el modelo puede ser anémico. El concepto existe, pero no expresa suficientemente su comportamiento.

25.4 Qué es un modelo expresivo

Un modelo expresivo representa datos y comportamiento del dominio de manera coherente. Las entidades protegen sus invariantes, los objetos de valor validan sus propios valores, los agregados controlan sus reglas internas y los servicios de dominio se usan cuando una operación no pertenece naturalmente a un solo objeto.

Por ejemplo, Turno puede expresar operaciones como reservar, cancelar, confirmar o registrar atención, siempre que esas responsabilidades correspondan a su ciclo de vida. Agenda puede controlar la incorporación de franjas sin superposición. Dinero puede asegurar moneda y monto válidos.

25.5 Responsabilidad dentro del dominio

Asignar responsabilidades significa decidir qué concepto debe conocer y proteger cada regla. No se trata de poner todo dentro de una entidad ni de poner todo en servicios. Se trata de ubicar cada comportamiento donde resulte natural según el dominio.

Una regla sobre el formato de un correo puede pertenecer al objeto de valor Correo electrónico. Una regla sobre transición de estado puede pertenecer a Turno. Una regla sobre franjas superpuestas puede pertenecer a Agenda. Una regla que coordina varios agregados puede pertenecer a un servicio de dominio.

25.6 Señales de modelo anémico

Algunas señales frecuentes son:

• Las entidades solo tienen atributos y métodos de lectura o escritura.
• Las reglas de negocio están en servicios genéricos o controladores.
• El mismo invariante se valida en varios lugares distintos.
• Los objetos pueden quedar en estados inválidos con facilidad.
• Las operaciones del dominio tienen nombres técnicos en lugar de nombres del negocio.
• Los conceptos del modelo no ayudan a entender cómo funciona el negocio.

25.7 Señales de modelo expresivo

Un modelo expresivo suele mostrar estas señales:

• Las operaciones importantes usan lenguaje ubicuo.
• Las entidades protegen cambios de estado y reglas propias.
• Los objetos de valor impiden valores inválidos.
• Los agregados controlan modificaciones internas.
• Los servicios de dominio se usan para operaciones que no pertenecen a una sola entidad.
• Las reglas se encuentran cerca del concepto que les da sentido.

25.8 Ejemplo: cancelar turno

En un enfoque anémico, un servicio externo podría cambiar directamente el estado de Turno a cancelado, modificar la franja, actualizar historial y decidir penalizaciones sin que Turno o sus conceptos relacionados protejan reglas.

En un enfoque más expresivo, Turno puede decidir si su estado permite cancelación. Una Política de cancelación puede evaluar anticipación y consecuencias. Agenda puede liberar la franja si corresponde. Cada concepto participa según su responsabilidad.

25.9 No todo comportamiento va dentro de entidades

Evitar un modelo anémico no significa poner todo dentro de las entidades. Algunas operaciones pertenecen a objetos de valor, agregados o servicios de dominio. Una entidad que conoce demasiadas cosas externas puede volverse difícil de mantener.

El objetivo es distribuir comportamiento de forma coherente. Si una regla pertenece naturalmente a una entidad, conviene ubicarla allí. Si involucra varios conceptos, puede requerir servicio de dominio. Si protege un valor, puede pertenecer al objeto de valor.

25.10 Servicios de dominio y riesgo de anemización

Los servicios de dominio son útiles, pero si se usan para todo, el modelo pierde expresividad. Cuando cada operación se resuelve en un servicio y las entidades solo contienen datos, los servicios se transforman en el verdadero modelo y las entidades quedan vacías de significado.

Antes de crear un servicio, conviene preguntar si la responsabilidad pertenece a una entidad, un objeto de valor o una raíz de agregado. El servicio debe aparecer cuando mejora el modelo, no cuando evita pensar responsabilidades.

25.11 Reglas cerca de los datos que protegen

Una regla suele ser más clara cuando está cerca de los datos y conceptos que protege. Si Rango horario debe tener inicio anterior a fin, esa regla pertenece al propio rango. Si Pedido no puede confirmarse vacío, esa regla pertenece al agregado Pedido.

Cuando la regla queda lejos del concepto, aumenta el riesgo de duplicarla, olvidarla o aplicarla de manera inconsistente.

25.12 Expresividad y pruebas

Un modelo expresivo facilita pruebas del dominio. Podemos probar directamente que un Turno atendido no puede cancelarse, que una Agenda rechaza franjas superpuestas o que Dinero no permite una moneda inválida.

En un modelo anémico, muchas pruebas terminan pasando por servicios grandes y con demasiadas dependencias, lo que dificulta aislar reglas concretas.

25.13 Tabla comparativa

La siguiente tabla resume diferencias habituales:

25.14 Preguntas para ubicar responsabilidades

Estas preguntas ayudan a distribuir responsabilidades:

• ¿Qué concepto conoce mejor esta regla?
• ¿Qué objeto debe impedir que se rompa este invariante?
• ¿La operación cambia el estado de una entidad específica?
• ¿La regla protege un objeto de valor?
• ¿La operación involucra varios agregados?
• ¿El nombre de la operación pertenece al lenguaje del dominio?
• ¿Estoy creando un servicio porque realmente aporta claridad o por comodidad?

25.15 Errores frecuentes

Al diseñar responsabilidades del dominio, suelen aparecer estos errores:

• Dejar entidades como simples estructuras de datos.
• Ubicar toda la lógica en servicios genéricos.
• Forzar comportamiento dentro de una entidad que no lo entiende.
• Duplicar reglas en varios lugares.
• Usar métodos técnicos que no expresan acciones del dominio.
• Crear objetos de valor sin reglas ni significado real.
• No validar con expertos si las operaciones reflejan el negocio.

25.16 Qué debes recordar de este tema

• Un modelo anémico contiene datos, pero expresa poco comportamiento del dominio.
• Un modelo expresivo ubica reglas y responsabilidades cerca de los conceptos adecuados.
• No todo comportamiento debe estar dentro de entidades.
• Los objetos de valor, agregados y servicios de dominio también pueden tener responsabilidades.
• Los servicios no deben convertirse en el lugar automático de toda regla.
• Las operaciones deben usar lenguaje ubicuo.
• Un modelo expresivo mejora comprensión, pruebas y mantenimiento.

25.17 Conclusión

La diferencia entre un modelo anémico y uno expresivo está en la ubicación del conocimiento del dominio. Un modelo expresivo no solo nombra conceptos: también muestra qué pueden hacer, qué reglas protegen y cómo colaboran. Esto mejora la claridad del análisis y prepara una base más sólida para el diseño del software.

En el próximo tema veremos patrones frecuentes de modelado, como catálogo, pedido, reserva, cuenta y movimiento.