Diferencia entre un servicio de dominio y la lógica de negocio
Durante mis años desarrollando software, uno de los puntos donde más he visto confusión, incluso entre programadores con experiencia, es la diferencia entre los servicios de dominio y la lógica de negocio. Es fácil caer en la trampa de pensar que son lo mismo o que se pueden intercambiar sin problema, pero en realidad cumplen roles bastante distintos dentro de una arquitectura bien diseñada 🧱.
Este artículo busca aclarar ese dilema, explicando con ejemplos concretos qué es un servicio de dominio, qué es la lógica de negocio, y cómo diferenciarlos con claridad para crear aplicaciones más mantenibles, escalables y limpias. ¡Vamos allá! 🚀
¿Qué es la lógica de negocio?
La lógica de negocio (también conocida como reglas de negocio) es el conjunto de decisiones, reglas, condiciones y procesos que definen cómo funciona un dominio específico. En otras palabras, es el "qué" hace tu software desde la perspectiva de negocio.
Por ejemplo, si estamos desarrollando una aplicación para un banco, parte de la lógica de negocio sería:
- Un cliente no puede retirar más dinero del que tiene.
- Un préstamo solo puede aprobarse si el cliente tiene un historial crediticio limpio.
- Una transferencia internacional debe aplicarle una comisión del 5%.
Estas reglas no dependen de la tecnología ni de la base de datos, ni de si estás usando Java, Python o C#. Son las reglas que te daría un experto del dominio (por ejemplo, un banquero) 📘.
¿Qué es un servicio de dominio?
Un servicio de dominio es un concepto que proviene del enfoque Domain-Driven Design (DDD). Es un componente que contiene lógica de negocio que no encaja de forma natural dentro de una entidad o un valor objeto, pero que sigue perteneciendo al dominio.
En otras palabras, un servicio de dominio es un orquestador de lógica de negocio que no pertenece a una sola entidad.
Los servicios de dominio se ubican en la capa del dominio y su función es modelar comportamientos del negocio que involucran múltiples entidades o reglas transversales. No deben contener lógica de infraestructura (como acceso a base de datos o servicios externos). Sólo reglas del dominio.
Un ejemplo clásico:
public class TransferenciaService
{
public void Transferir(Cuenta origen, Cuenta destino, decimal monto)
{
if (origen.Saldo < monto)
throw new InvalidOperationException("Fondos insuficientes");
origen.Debitar(monto);
destino.Acreditar(monto);
}
}
Este servicio no tiene dependencia a una base de datos ni frameworks externos, sólo encapsula una operación que afecta a dos entidades (Cuenta), y por tanto no puede pertenecer exclusivamente a ninguna. 😊
Diferencias clave entre un servicio de dominio y la lógica de negocio
Ahora que entendemos qué es cada uno, veamos las diferencias fundamentales:
| Característica | Lógica de negocio | Servicio de dominio |
|---|---|---|
| ¿Qué es? | Reglas que definen el comportamiento del negocio | Componente que agrupa lógica de negocio que no cabe en entidades |
| ¿Dónde vive? | Dentro de entidades, objetos de valor o servicios | En la capa de dominio |
| ¿Puede acceder a infraestructura? | No | No |
| ¿Orquesta otras entidades? | A veces sí, pero no es su rol principal | Sí, ese es su rol principal |
| ¿Está centrado en un solo objeto? | Generalmente sí | Generalmente no |
En resumen, toda lógica de negocio puede formar parte de un servicio de dominio, pero no todo servicio de dominio está limitado a una sola regla de negocio. Por eso, aunque los dos están relacionados, no son equivalentes. 🧠
¿Y qué pasa con los servicios de aplicación?
Una confusión común es mezclar los servicios de dominio con los servicios de aplicación.
Los servicios de aplicación están en la capa superior (por ejemplo, en un controlador) y se encargan de coordinar la ejecución de casos de uso, incluyendo llamadas a servicios de dominio, repositorios, etc.
Un ejemplo típico en un sistema con arquitectura por capas:
public class TransferenciaAppService
{
private readonly TransferenciaService _servicioDominio;
private readonly ICuentaRepository _repositorio;
public TransferenciaAppService(TransferenciaService servicioDominio, ICuentaRepository repositorio)
{
_servicioDominio = servicioDominio;
_repositorio = repositorio;
}
public void EjecutarTransferencia(int cuentaOrigenId, int cuentaDestinoId, decimal monto)
{
var cuentaOrigen = _repositorio.ObtenerPorId(cuentaOrigenId);
var cuentaDestino = _repositorio.ObtenerPorId(cuentaDestinoId);
_servicioDominio.Transferir(cuentaOrigen, cuentaDestino, monto);
_repositorio.Guardar(cuentaOrigen);
_repositorio.Guardar(cuentaDestino);
}
}Este servicio de aplicación tiene acceso a infraestructura (repositorios), pero la lógica de negocio real está en el servicio de dominio. Es decir: la lógica de negocio vive en el dominio, no en la aplicación. 🎯
Beneficios de separar correctamente estas responsabilidades
Separar claramente la lógica de negocio dentro de servicios de dominio, y dejar la coordinación a los servicios de aplicación, tiene muchos beneficios:
- ✅ Mayor mantenibilidad: cada componente tiene una responsabilidad clara.
- ✅ Reutilización de lógica de negocio: puedes usar los mismos servicios de dominio en distintos casos de uso.
- ✅ Facilidad para hacer testing: puedes probar la lógica sin necesidad de instanciar toda la aplicación.
- ✅ Mejor comprensión del dominio: los conceptos del negocio están representados directamente en el código.
Conclusión
Cuando comencé en el mundo del desarrollo, solía meter toda la lógica directamente en los controladores o en clases de servicios sin distinguir claramente entre responsabilidades. Pero al adoptar enfoques como DDD y separar la lógica de negocio de los servicios de aplicación, y utilizar correctamente los servicios de dominio, todo se volvió mucho más limpio, mantenible y comprensible.
Recuerda siempre:
La lógica de negocio son las reglas. El servicio de dominio es quien las ejecuta cuando no caben dentro de una sola entidad.
Espero que esta explicación te haya sido útil. Y si tienes un equipo de desarrollo, compártela: muchas veces este tipo de confusiones surgen por falta de ejemplos concretos o por no hablar un lenguaje común. 👥
Jorge García
Fullstack developer