Una de las distinciones más importantes en modelado de dominio es separar el dominio del problema de la solución técnica. El dominio del problema describe la realidad que el software debe comprender: conceptos del negocio, reglas, restricciones, eventos, estados y vocabulario. La solución técnica describe cómo construiremos el sistema: pantallas, bases de datos, clases, servicios, controladores, APIs, frameworks, servidores y mecanismos de persistencia.
Ambas dimensiones son necesarias, pero no deben mezclarse demasiado pronto. Si durante el análisis pensamos inmediatamente en tablas, endpoints o componentes de interfaz, corremos el riesgo de perder de vista el problema real. En cambio, si primero entendemos el dominio, las decisiones técnicas posteriores tendrán una base más clara.
El dominio del problema es el área de conocimiento donde existe la necesidad que el software debe atender. Incluye las personas, conceptos, procesos, documentos, reglas, restricciones y decisiones propias del negocio o actividad.
Por ejemplo, si se desarrolla un sistema de turnos médicos, el dominio del problema incluye pacientes, profesionales, especialidades, agendas, horarios disponibles, reservas, cancelaciones, ausencias, confirmaciones y reglas de atención. Nada de eso depende todavía de si el sistema será web, móvil, de escritorio o una API.
La solución técnica es la forma concreta en que se decide implementar el sistema. Incluye arquitectura, lenguaje de programación, base de datos, interfaz de usuario, protocolos, servicios externos, frameworks, componentes, clases, archivos, tablas y despliegue.
En el sistema de turnos, la solución técnica podría incluir una aplicación web, una base de datos relacional, una tabla llamada turnos, una clase Turno, un controlador para reservas, un servicio de notificaciones y una API para consultar disponibilidad. Estos elementos son importantes, pero pertenecen al diseño e implementación, no al primer análisis del dominio.
La solución técnica debe servir al dominio, no reemplazarlo. Un sistema técnicamente elegante puede fallar si representa mal los conceptos y reglas del negocio.
La siguiente tabla resume diferencias habituales entre mirar el problema desde el dominio y mirarlo desde la solución técnica:
| Aspecto | Dominio del problema | Solución técnica |
|---|---|---|
| Pregunta principal | ¿Cómo funciona el negocio? | ¿Cómo construiremos el sistema? |
| Elementos típicos | Paciente, Turno, Agenda, Reserva, Cancelación. | Tabla, clase, formulario, endpoint, servicio. |
| Lenguaje | Vocabulario usado por usuarios y expertos del negocio. | Vocabulario técnico usado por el equipo de desarrollo. |
| Objetivo | Comprender reglas, significados y relaciones. | Implementar una solución funcional, mantenible y eficiente. |
| Momento principal | Análisis y validación del conocimiento. | Diseño, construcción, pruebas técnicas y despliegue. |
Mezclar dominio y solución técnica desde el inicio puede producir modelos confusos. Si en un diagrama de dominio aparecen elementos como PantallaAltaTurno, TablaProfesionales, ControladorReserva o TurnoDTO, el modelo empieza a describir la implementación en lugar del negocio. Eso dificulta la validación con usuarios y puede ocultar reglas importantes.
Cuando el modelo se llena de tecnología, los expertos del negocio dejan de reconocer su propio mundo. En lugar de revisar si las reglas son correctas, deben interpretar términos técnicos que no forman parte de su trabajo cotidiano. El modelo pierde su capacidad de ser una herramienta compartida.
Separar ambos planos no significa ignorar la tecnología. Significa postergar ciertas decisiones hasta tener suficiente comprensión del problema.
Supongamos que un equipo modela un sistema de turnos y escribe lo siguiente como conceptos principales:
Estos nombres pueden aparecer en la solución técnica, pero no describen el dominio del problema. Un experto del consultorio probablemente hablará de paciente, profesional, agenda, horario, turno reservado, turno cancelado, confirmación, ausencia o sobreturno.
Una versión más orientada al dominio sería:
Esta segunda lista permite conversar sobre reglas reales: un profesional atiende una o varias especialidades, una agenda contiene franjas horarias, un paciente reserva un turno, una cancelación puede liberar una franja y una confirmación puede evitar ausencias.
Un concepto del negocio existe porque tiene significado para el dominio. Un artefacto técnico existe porque ayuda a implementar la solución. A veces tienen nombres parecidos, pero no son lo mismo. Por ejemplo, puede existir el concepto de Turno en el dominio y también una clase Turno en el código o una tabla turnos en la base de datos.
La diferencia está en la intención. En el dominio, Turno significa una asignación de atención en una fecha y horario, con un paciente, un profesional y un estado. En la base de datos, turnos es una estructura para guardar datos. En el código, una clase Turno es una decisión de diseño que puede incluir atributos, métodos y validaciones.
El modelo de dominio debe cuidar primero el significado. Luego, durante el diseño, se decidirá cómo llevar ese significado a estructuras técnicas.
Algunas señales permiten detectar que un modelo de dominio se está contaminando con detalles técnicos:
Un modelo orientado al dominio suele tener características claras:
El buen modelo de dominio no elimina la necesidad de diseño técnico. Lo que hace es preparar mejor ese diseño.
Separar dominio y solución técnica requiere abstracción. Abstraer significa quedarse con lo esencial para el propósito actual y dejar fuera detalles que todavía no aportan. En análisis de dominio, lo esencial es entender el significado de los conceptos y reglas del negocio.
Por ejemplo, para comprender una reserva de turno, al comienzo no necesitamos decidir si se guardará en MySQL, PostgreSQL o MongoDB. Tampoco necesitamos definir el color del botón de confirmación. Primero necesitamos saber cuándo una reserva es válida, qué estados puede tener, quién puede crearla, quién puede cancelarla y qué consecuencias produce.
La abstracción no simplifica por descuido; simplifica para pensar mejor.
Separar no significa aislar para siempre. El conocimiento del dominio debe alimentar la solución técnica. Una vez que se comprenden conceptos y reglas, el equipo puede decidir cómo representarlos en código, datos, interfaces y servicios.
Por ejemplo, si el dominio indica que un turno puede estar disponible, reservado, cancelado, atendido o ausente, esa información puede influir en un diagrama de estados, en validaciones, en casos de prueba, en el diseño de la base de datos y en las opciones visibles para el usuario. Si el dominio indica que una cancelación requiere cierta anticipación, esa regla debe aparecer en la implementación y no quedar como comentario informal.
Los expertos del dominio son las personas que conocen cómo funciona el negocio. Pueden ser usuarios avanzados, responsables operativos, especialistas del área, administradores, médicos, contadores, vendedores, docentes o cualquier persona que entienda las reglas reales del trabajo.
Su participación es clave porque muchas reglas no están escritas o aparecen incompletas en documentos formales. Los expertos pueden explicar excepciones, prioridades, significados de términos, políticas internas y situaciones que ocurren en la práctica.
Un modelo demasiado técnico aleja a estos expertos. Un modelo de dominio bien expresado los invita a participar, corregir, discutir y validar.
Durante el análisis, estas preguntas ayudan a mantener el foco en el dominio:
Distinguir el dominio del problema de la solución técnica es una habilidad esencial para modelar bien. El dominio nos dice qué debe entender el software; la técnica nos permite construir una respuesta concreta. Cuando se mezclan sin cuidado, aparecen modelos difíciles de validar, reglas mal ubicadas y decisiones prematuras.
En este tema vimos cómo separar ambos planos, por qué esa separación mejora la comprensión y cómo reconocer señales de un modelo demasiado técnico. En el próximo tema veremos cómo se relacionan requerimientos, casos de uso, UML y modelo de dominio dentro del trabajo de análisis.