19. Servicios de dominio: operaciones que no pertenecen naturalmente a una entidad
19.1 Introducción
En un modelo de dominio muchas reglas y operaciones pueden ubicarse naturalmente en entidades u objetos de valor. Un Turno puede saber si está cancelado. Un Rango horario puede validar que su inicio sea anterior a su fin. Un Pedido puede calcular su total. Pero algunas operaciones importantes no pertenecen claramente a un solo objeto.
Cuando una operación del negocio involucra varios conceptos y no encaja naturalmente en una entidad u objeto de valor, puede aparecer un servicio de dominio. Su función es representar una acción o regla del dominio sin forzarla dentro de un concepto que no debería tener esa responsabilidad.
19.2 Imagen conceptual de servicio de dominio
19.3 Qué es un servicio de dominio
Un servicio de dominio es una operación significativa del negocio que no se ubica de manera natural en una entidad o en un objeto de valor. Suele coordinar varios conceptos del dominio, aplicar una política o resolver una decisión que involucra más de un objeto.
Por ejemplo, Calcular disponibilidad de turnos puede necesitar Agenda, Profesional, Especialidad, Franjas horarias, Bloqueos y Turnos existentes. Si esa lógica no pertenece claramente a una sola entidad, puede modelarse como servicio de dominio.
19.4 Cuándo aparece la necesidad
La necesidad de un servicio de dominio aparece cuando una operación:
- Involucra varios conceptos del dominio.
- No pertenece naturalmente a una única entidad.
- Representa una regla o política importante del negocio.
- Coordina información para producir una decisión o resultado.
- No debería quedar como simple función técnica sin significado.
El servicio evita que una entidad acumule responsabilidades que no le corresponden.
19.5 Ejemplo: calcular disponibilidad
En un sistema de turnos, calcular disponibilidad puede requerir revisar la agenda del profesional, las franjas horarias, los turnos ya reservados, bloqueos por ausencia, duración según especialidad y reglas de sobreturnos.
Podríamos preguntar: ¿debería Profesional calcular disponibilidad?, ¿debería hacerlo Agenda?, ¿debería hacerlo Especialidad? Si la operación depende de todos esos conceptos y expresa una regla del dominio, puede tener sentido modelar un servicio llamado Servicio de disponibilidad o Calculador de disponibilidad.
19.6 Ejemplo: aplicar política de cancelación
Cancelar un turno puede implicar más que cambiar un estado. Puede requerir evaluar anticipación, tipo de paciente, historial de inasistencias, motivo de cancelación y reglas de penalización. Si esa política es compleja y no pertenece solo a Turno, puede modelarse como servicio de dominio.
El servicio no reemplaza a la entidad Turno. La entidad puede seguir protegiendo invariantes propios, mientras el servicio coordina una política más amplia.
19.7 Diferencia con una entidad
Una entidad tiene identidad y continuidad. Un servicio de dominio no tiene identidad propia. No representa una cosa del negocio que deba seguirse a través del tiempo. Representa una operación, regla o coordinación.
Por ejemplo, Paciente es una entidad. Turno es una entidad. Política de cancelación o Calculador de disponibilidad no son entidades si solo representan comportamiento. No necesitamos distinguir una instancia histórica de otra como parte central del dominio, salvo que el negocio tenga reglas específicas sobre versiones de políticas.
19.8 Diferencia con un objeto de valor
Un objeto de valor representa un valor significativo que se compara por atributos. Un servicio de dominio representa comportamiento. Dinero, Rango horario o Dirección pueden ser objetos de valor. Calcular total, evaluar disponibilidad o aplicar penalización son operaciones.
Si el elemento tiene datos, igualdad por atributos y significado como valor, puede ser objeto de valor. Si lo principal es una operación de dominio sin identidad, puede ser servicio.
19.9 Diferencia con servicio de aplicación
Un servicio de aplicación coordina casos de uso, seguridad, transacciones, acceso a repositorios, envío de respuestas o interacción con infraestructura. Un servicio de dominio contiene lógica del negocio.
Por ejemplo, un servicio de aplicación puede recibir la solicitud de cancelar turno, cargar el turno desde un repositorio y guardar cambios. El servicio de dominio puede evaluar la política de cancelación y decidir si corresponde penalización.
19.10 Diferencia con utilidad técnica
Una utilidad técnica realiza tareas generales como formatear fechas, enviar correos, convertir archivos o generar identificadores. Eso no es servicio de dominio, aunque sea útil para el sistema.
Un servicio de dominio debe estar nombrado con lenguaje del negocio y resolver una operación significativa para el dominio. Si el nombre suena técnico y no puede explicarse a expertos del negocio, probablemente no sea un servicio de dominio.
19.11 Servicios de dominio y lenguaje ubicuo
Los servicios de dominio deben usar nombres del lenguaje ubicuo. Nombres como Evaluador de elegibilidad, Calculador de disponibilidad, Política de cancelación o Servicio de asignación de turnos pueden tener sentido si el negocio reconoce esas operaciones.
Evitemos nombres genéricos como Manager, Helper, Processor o Util si no dicen nada sobre el dominio. Un nombre pobre oculta la regla que el servicio representa.
19.12 Servicios sin estado propio
Por lo general, un servicio de dominio no tiene estado propio persistente. Puede recibir entidades, objetos de valor y parámetros, aplicar reglas y devolver un resultado. Si empieza a tener identidad, historial y ciclo de vida propio, quizás no sea un servicio sino un concepto del dominio que debe modelarse de otra manera.
Esto no significa que la operación no pueda depender de datos. Significa que esos datos pertenecen a entidades, objetos de valor, políticas o repositorios conceptuales, no al servicio como identidad central.
19.13 Tabla de ejemplos
La siguiente tabla muestra posibles servicios de dominio:
| Servicio de dominio | Conceptos que coordina | Responsabilidad |
|---|---|---|
| Calculador de disponibilidad | Agenda, Profesional, Turno, Franja horaria. | Determinar horarios disponibles según reglas. |
| Política de cancelación | Turno, Paciente, Cancelación, Historial. | Decidir si una cancelación es válida y si genera penalización. |
| Evaluador de elegibilidad | Paciente, Cobertura, Especialidad. | Determinar si el paciente puede acceder a una prestación. |
| Calculador de precio | Pedido, Ítems, Descuentos, Impuestos. | Calcular importe final según reglas comerciales. |
| Asignador de profesional | Solicitud, Profesional, Especialidad, Agenda. | Elegir profesional disponible según criterios del dominio. |
19.14 Preguntas para identificar servicios de dominio
Estas preguntas ayudan a decidir si una operación puede ser servicio de dominio:
- ¿La operación representa conocimiento del negocio?
- ¿Involucra varias entidades u objetos de valor?
- ¿No pertenece claramente a una sola entidad?
- ¿Tiene nombre natural en el lenguaje ubicuo?
- ¿Aplica una política, cálculo o decisión importante?
- ¿Sería incorrecto ubicarla dentro de una entidad solo por comodidad?
- ¿No se trata simplemente de una tarea técnica?
19.15 Riesgo de abusar de servicios
Los servicios de dominio son útiles, pero pueden usarse en exceso. Si toda la lógica se coloca en servicios y las entidades quedan como simples datos, el modelo se vuelve anémico: tiene nombres de dominio pero poco comportamiento propio.
Antes de crear un servicio, conviene preguntar si la responsabilidad pertenece naturalmente a una entidad u objeto de valor. El servicio debe usarse cuando realmente aporta claridad, no como lugar automático para cualquier regla.
19.16 Errores frecuentes
Al modelar servicios de dominio, suelen aparecer estos errores:
- Crear servicios para toda operación, dejando entidades sin comportamiento.
- Usar nombres técnicos como Helper, Manager o Utils.
- Confundir servicios de dominio con servicios de aplicación.
- Ubicar lógica de infraestructura dentro del dominio.
- Crear un servicio cuando la regla pertenece claramente a una entidad.
- No validar si el servicio representa un concepto reconocido por el negocio.
- Permitir que el servicio acumule demasiadas responsabilidades distintas.
19.17 Qué debes recordar de este tema
- Un servicio de dominio representa una operación importante del negocio.
- Se usa cuando la operación no pertenece naturalmente a una entidad u objeto de valor.
- No tiene identidad propia como una entidad.
- Debe nombrarse con lenguaje ubicuo y expresar conocimiento del dominio.
- No debe confundirse con servicios de aplicación ni utilidades técnicas.
- Puede coordinar varias entidades, objetos de valor y políticas.
- Debe usarse con moderación para no producir modelos anémicos.
19.18 Conclusión
Los servicios de dominio ayudan a ubicar operaciones del negocio que no pertenecen naturalmente a un solo concepto. Permiten representar cálculos, políticas y decisiones que coordinan varios elementos del modelo sin forzar responsabilidades dentro de entidades incorrectas.
En el próximo tema estudiaremos los agregados, que permiten definir límites de consistencia y proteger reglas internas del dominio.