Modelo De Dominio (Entity Framework)

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

...