Antes de diseñar una solución técnica, el equipo necesita comprender el dominio del negocio: los conceptos, reglas, procesos y relaciones propias del área donde el software será utilizado. El modelado de dominio ayuda a construir esa comprensión.
Un modelo de dominio representa los conceptos principales de un problema y cómo se relacionan entre sí. No busca mostrar pantallas, bases de datos ni código. Busca responder qué cosas existen en el negocio, qué significan y qué reglas las conectan.
Comprender el dominio reduce malentendidos y permite que usuarios, analistas y desarrolladores compartan un lenguaje común.
El dominio es el área de conocimiento o actividad que el sistema debe apoyar. Puede ser educación, salud, comercio, logística, banca, biblioteca, reservas, facturación, recursos humanos u otra realidad específica.
Por ejemplo:
Un modelo de dominio es una representación conceptual de los elementos importantes del negocio y sus relaciones. Ayuda a explicar cómo se entiende el problema sin entrar todavía en detalles técnicos de implementación.
Un modelo de dominio puede incluir:
Puede representarse con diagramas, tablas, listas o una combinación de formatos. Lo importante es que ayude a comprender y discutir el dominio.
Los conceptos del negocio son las ideas principales con las que trabajan los usuarios. Suelen corresponder a cosas, personas, documentos, eventos, transacciones o estados importantes.
Ejemplos:
| Dominio | Conceptos posibles |
|---|---|
| Biblioteca | Libro, socio, préstamo, devolución, reserva, multa. |
| Ventas | Cliente, producto, pedido, factura, pago, descuento. |
| Educación | Alumno, curso, docente, inscripción, evaluación, certificado. |
| Salud | Paciente, profesional, turno, especialidad, consulta, estudio. |
Identificar conceptos ayuda a descubrir datos, reglas, casos de uso y responsabilidades del sistema.
Los conceptos no existen aislados. Se relacionan entre sí. Entender esas relaciones es fundamental para evitar errores de interpretación.
Ejemplos de relaciones:
Estas relaciones suelen revelar reglas importantes. Por ejemplo, si un libro puede tener varios ejemplares, el préstamo quizá no debe asociarse al título general, sino a un ejemplar específico.
Los atributos describen información importante de un concepto. No todos los datos posibles deben incluirse en un modelo de dominio inicial; conviene registrar los que ayudan a comprender reglas o decisiones.
| Concepto | Atributos posibles | Por qué importan |
|---|---|---|
| Socio | Número de socio, estado, fecha de alta. | Permiten validar si puede pedir préstamos. |
| Préstamo | Fecha de inicio, fecha de vencimiento, fecha de devolución. | Permiten calcular vencimientos y multas. |
| Producto | Precio, stock, categoría, estado. | Permiten vender, filtrar y controlar disponibilidad. |
| Turno | Fecha, hora, estado, profesional, paciente. | Permiten gestionar agenda y disponibilidad. |
Las reglas de negocio definen condiciones, restricciones o políticas del dominio. Son esenciales porque determinan qué acciones son válidas y qué resultados deben producirse.
Ejemplos:
Muchas reglas de negocio se transforman luego en requerimientos, validaciones, criterios de aceptación y pruebas.
Uno de los beneficios más importantes del modelado de dominio es crear un lenguaje común. Los usuarios y el equipo técnico pueden usar las mismas palabras con el mismo significado.
Sin lenguaje común aparecen confusiones. Por ejemplo, "cliente" puede significar una persona registrada, una empresa que compra, un contacto comercial o un usuario que paga. Si el término no se aclara, el sistema puede quedar mal diseñado.
Para mejorar el lenguaje común conviene:
En muchos dominios hay conceptos que parecen similares, pero no significan lo mismo. Distinguirlos evita errores.
| Conceptos | Diferencia posible |
|---|---|
| Libro y ejemplar | El libro es la obra; el ejemplar es una copia física específica que puede prestarse. |
| Alumno y usuario | Alumno es un rol académico; usuario es una cuenta de acceso al sistema. |
| Pedido y factura | El pedido registra una intención de compra; la factura documenta una operación fiscal. |
| Reserva y turno | El turno puede ser un espacio disponible; la reserva es la asignación de ese espacio a alguien. |
| Producto y stock | El producto describe lo que se vende; el stock indica cantidad disponible. |
Algunos conceptos del dominio tienen estados. Identificar esos estados ayuda a comprender reglas y transiciones válidas.
Ejemplos:
Al identificar estados conviene preguntar qué eventos provocan cambios y qué transiciones no están permitidas.
Un procedimiento simple para comenzar es:
El modelo inicial no necesita ser perfecto. Debe ser útil para aprender y conversar.
Para una biblioteca, un modelo de dominio inicial podría identificar:
| Concepto | Descripción | Relaciones o reglas |
|---|---|---|
| Socio | Persona registrada que puede retirar libros. | Puede tener varios préstamos activos, con un límite definido. |
| Libro | Obra disponible en el catálogo. | Puede tener uno o más ejemplares. |
| Ejemplar | Copia física de un libro. | Puede estar disponible, prestado, reservado o perdido. |
| Préstamo | Registro de entrega de un ejemplar a un socio. | Tiene fecha de inicio, vencimiento y devolución. |
| Reserva | Solicitud de un socio sobre un libro o ejemplar. | Puede estar activa, cancelada o vencida. |
Este modelo permite discutir reglas antes de construir pantallas o base de datos.
Para una tienda en línea, algunos conceptos centrales podrían ser:
Algunas relaciones y reglas posibles:
Un modelo de dominio no es lo mismo que un modelo de base de datos, aunque pueden estar relacionados. El modelo de dominio busca comprender conceptos del negocio. El modelo de base de datos define cómo se almacenará la información.
| Modelo de dominio | Modelo de base de datos |
|---|---|
| Usa lenguaje del negocio. | Usa estructuras de almacenamiento. |
| Puede omitir detalles técnicos. | Debe definir tablas, claves, índices o tipos de datos. |
| Sirve para comprender y conversar. | Sirve para implementar persistencia. |
| Puede existir antes de decidir la tecnología. | Depende de decisiones técnicas. |
Convertir un modelo de dominio directamente en base de datos sin análisis puede generar problemas. Hay que considerar rendimiento, normalización, historial, integraciones y necesidades técnicas.
El modelo de dominio tampoco es automáticamente el código. Puede inspirar clases, entidades, módulos o servicios, pero la implementación requiere decisiones adicionales.
Por ejemplo, en el dominio existe el concepto "Pedido". En el código puede representarse como una clase, una entidad, una tabla, un documento, un servicio o una combinación de elementos según la arquitectura elegida.
La relación entre dominio y código debe cuidarse para que el sistema mantenga nombres y responsabilidades comprensibles. Cuando el código se aleja demasiado del lenguaje del dominio, aumenta la dificultad de mantenimiento.
Al modelar el dominio suelen aparecer errores como:
Algunas prácticas recomendables son:
El modelado de dominio permite comprender los conceptos fundamentales del negocio antes de tomar decisiones técnicas. Ayuda a que el equipo hable el mismo lenguaje que los usuarios y evita construir una solución basada en suposiciones incorrectas.
Para quien comienza, la idea principal es esta: antes de modelar pantallas, tablas o clases, conviene entender qué conceptos existen en el negocio, cómo se relacionan y qué reglas los gobiernan.
En el próximo tema veremos una introducción a UML y otros diagramas de apoyo, que permiten representar distintos aspectos del análisis y diseño de software.