El Dominio: Donde Viven las Reglas del Juego
▸ arquitectura-hexagonal/disenando-el-dominioCuando diseñás software, hay una capa que no podés darte el lujo de improvisar: el dominio.
No importa qué tecnología uses ni cómo te conectes a una base de datos. Lo que de verdad importa es qué hace tu sistema y bajo qué reglas.
Ese conjunto de reglas es lo que vive en el dominio.
¿Qué es el Dominio?
El dominio es la parte del sistema que representa el problema que estás resolviendo.
Si tu software desapareciera mañana, el dominio sería la única parte que vale la pena rescatar.
Es donde definís:
- Cómo se comportan las entidades centrales del sistema.
- Qué está permitido y qué no.
- Qué significa “ganar”, “validar”, “terminar”, “repetir”, “cancelar”, etc.
El Ajedrez Como Metáfora
Volvamos al ejemplo del ajedrez.
No importa si estás jugando en un tablero físico, en una app de celular o por mensajes de texto.
Las reglas del juego no cambian:
- Cómo se mueve cada pieza.
- Qué es jaque mate.
- Qué acciones son válidas y cuáles no.
- Qué pasa si abandonás la partida.
Esas son reglas del dominio del ajedrez. Y no dependen de la plataforma.
¿Qué Debería Estar en el Dominio?
- Reglas de negocio claras: como “el rey no puede moverse a una casilla amenazada”.
- Comportamientos consistentes: como “cuando muevo una pieza, cambia el turno”.
- Lógica pura: lógica que podés ejecutar sin conectarte a nada externo.
- Entidades que tienen sentido en tu problema real: en este caso, una Partida, un Tablero, un Jugador.
¿Qué No Debería Estar en el Dominio?
Todo lo que no tiene que ver con las reglas del negocio debería estar fuera.
Por ejemplo:
- Cómo llegan los datos (HTTP, formularios, interfaces gráficas).
- Dónde se guardan (bases de datos, archivos, servicios externos).
- Qué formatos usan los datos (JSON, XML, texto plano).
- Cómo se notifican los errores (logs, emails, alertas).
Eso pertenece al mundo exterior. El dominio no debería depender de nada de eso.
¿Por Qué Separarlo?
Separar el dominio te permite:
- ✨ Pensar con claridad: podés hablar con expertos del negocio sin mencionar tecnología.
- 🧪 Testear con facilidad: sin levantar servidores ni preparar entornos complejos.
- 🛠 Hacer cambios sin miedo: la lógica de negocio no cambia cuando cambiás la tecnología.
- 🔁 Reutilizar el núcleo: podés usar la misma lógica en una app web, móvil o de consola.
Un dominio bien diseñado es como un buen juego
En un juego las reglas son claras. No importa si jugás con piezas de madera, de plástico o en una app: sabés cómo jugar.
Un buen sistema de software debería ser igual. El dominio expresa las reglas fundamentales. Lo demás es contexto. Lo visual, lo técnico, lo externo puede cambiar. Pero las reglas que definen cómo funciona tu sistema deben mantenerse firmes y comprensibles.
Diseñar el dominio es diseñar el significado de tu sistema. Y si lo hacés bien, podés cambiar todo lo demás sin perder el valor real del software.
Porque el valor no está en el tablero. Está en el juego en sí. El dominio no es un detalle técnico. Es el corazón del producto.