MODELO DE DOMINIO.

El Modelo de Dominio es una representación visual estática del entorno real objeto del
proyecto.
Es decir, un diagrama con los objetos que existen (reales) relacionados con el proyecto que
vamos a acometer y las relaciones que hay entre ellos. Pero no son clases de software (aunque
algunos objetos del Modelo de Dominio pueden terminar siéndolo).
Nota: Se llama "de Dominio" para distinguirlo del Modelo de Negocio (Model of Business) que
en RUP (Rational Unified Process) es un concepto más amplio. El MOB de RUP incluye toda la
organización, sus relaciones, sus procesos... todo. Sin embargo, el Modelo de Dominio se
centra en una parte del negocio, la relacionada con el ámbito del proyecto. En este contexto el
término "dominio" representa una parte del "negocio".
Nota: Se dice que es estática porque no representa la interacción en el tiempo de los objetos,
sino que representa una visión "parada" de las clases y sus interacciones.
Cuál es su Objetivo:
El Modelo de Dominio ayuda a comprender los conceptos que utilizan los usuarios, los
conceptos con los que trabajan y con los que deberá trabajar nuestra aplicación.
Cómo se Elabora
La elaboración del Modelo de Dominio requiere la participación de Expertos de Negocio.
El proceso para su elaboración tiene tres pasos:
1. Identificar las Clases Conceptuales.
2. Dibujarlas en un Diagrama de Clases.
3. Añadir Relaciones y Atributos.
1.- Identificar las Clases Conceptuales
Una "clase conceptual" es cualquier cosa que pertenezca al dominio. Por ejemplo, personas,
máquinas, lugares... Y también elementos intangibles como conceptos (venta, permiso,
perfil...).
La mejor forma de identificar estas clases es escuchando a los Expertos de Negocio. Bastará
una reunión con ellos en la que se comente todo el dominio de la aplicación para identificar las
clases conceptuales. ¿Cómo? Es fácil, las clases suelen ser los sustantivos utilizados por los
expertos al describir el dominio:
"El cliente se presenta en el mostrador y solicita una operación".
"La solicitud se archiva en el expediente y se envía una notificación al usuario."
Hay otras formas, como reutilizar modelos existentes o recurrir a listas predefinidas. Pero
deben utilizarse sólo como medios complementarios a la escucha de los expertos.
2. Dibujar un Diagrama de Clases
El Modelo de Dominio queda recogido en un diagrama (parecido al Diagrama de Clases pero
más simplificado).
Representamos cada clase por su nombre, dentro de un recuadro.

Nota: Un error habitual es confundir las clases conceptuales con clases de software. Puede
que finalmente, al realizar el diseño de clases, haya clases de software con el mismo nombre
que las clases conceptuales del modelo de dominio. Pero en ningún caso son las mismas. Y
aunque las diferencias puedan ser sutiles, si se aplican atributos y características propias del
software a las clases conceptuales se estarán incluyendo restricciones innecesarias para el
diseño de clases. Y eso es malo.
No olvidemos que el objetivo es comprender, no documentar. Así que el Modelo de Dominio
sólo recogerá las clases relevantes para el problema que queremos entender en ese momento.
3. Añadir Relaciones y Atributos
Entre las clases existen relaciones Se identifican fácilmente como los verbos utilizados por los
expertos de dominio:
"El cliente se presenta en el mostrador y solicita una operación".
"La solicitud se archiva en el expediente y se envía una notificación al usuario."
En el diagrama, cada relación queda representada por una línea que une las clases
relacionadas (no sus atributos).

Nota: Las relaciones del Modelo de Dominio no son relaciones entre clases, son relaciones
entre instancias de las clases. Es decir, el Modelo de Dominio no representa relaciones de
herencia, uso, etc. sino relaciones entre instancias de estas clases, que pueden ser "es una
parte de", "es resultado de", "es una descripción de", "utiliza a", "pertenece a", etc.
Cada relación tiene también una multiplicidad (si es 1 a 1, n a 1, 0 ó 1...). Y esa no es tan fácil
encontrarla. No suele figurar en las expresiones de los expertos. Para identificar la
multiplicidad hay que tomar un papel activo y hacer preguntas concretas a los expertos,
preguntas del tipo "¿Cuántas operaciones pueden incluirse en cada solicitud?" y proponerles
situaciones aclaratorias ("Si un cliente llega a una sucursal que no es la habitual... ¿se le abre
un nuevo expediente?"). Con algo de experiencia, no suele ser difícil completar el Modelo de
Dominio en poco más de una hora.
La multiplicidad de cada relación se representa sobre su línea, junto a la clase correspondiente.

Y por último, resta identificar los atributos de cada clase.

En una notación completa, de cada atributo podemos indicar:

visibilidad nombre : tipo multiplicidad = valor por defecto {propiedades}
Algunos ejemplos:
 +nombre:texto
 +apodo:texto [0..1]
 -/total:importe
 +PI:Real {solo lectura}
Los valores posibles para la visibilidad son: + público, - privado, # protegido y / campo
calculado.
En un modelo de negocio, los atributos son "datos simples". Es decir, nunca pueden ser otras
clases. Si una clase conceptual está formada por otra clase conceptual (por ejemplo,
una póliza tiene beneficiarios), Debemos establecer una relación entre ellos (La póliza tiene
beneficiarios).
"Datos simples" son los textos, números, booleanos, fechas, listas de valores... Y también otros
un poco más avanzados, como las cantidades (compuestas de valor y unidad), las direcciones
(varios textos), el dni (un número y una letra), un número de serie... y en general cualquier
atributo que no alcance la categoría de "clase".
Nota: Las clases conceptuales no tienen claves externas. La mejor forma de expresar estas
situaciones es mediante una relación entre las clases.
No olvidemos que el objetivo es comprender, no documentar. Así que sólo representaremos
las relaciones y los atributos que sean relevantes para el problema que queremos entender en
ese momento.