Hola,
Se nos ocurrió aclarar un poco de qué hablamos cuándo hablamos de modelo de dominio.
En términos generales, un modelo de dominio es una representación
visual de los tipos de objetos (abstractos) más importantes que se encuentran en un dominio de problema en particular. Como puntualiza Craig Larman (ver
http://www.craiglarman.cn/book_applying/domain_model_1.pdf), podemos pensar en él como si fuera un glosario o un diccionario visual que describe las clases
conceptuales significativas de un dominio determinado.
Así por ejemplo, si estudiamos cómo las compañías realizan sus operaciones de venta, nos encontaremos con clases conceptuales como Cliente, Producto, Pedido de Venta, Ítem de Pedido, Factura, Ítem de Factura, etc.; cada una de ellas, por supuesto, tendrá propiedades (CUIT, razón social, etc.)
Estas clases forman parte del vocabulario del problema que estamos analizando y suelen ser la base para identificar, luego, (parte de las) clases de diseño e implementación (y también tablas y archivos).
¿Cuál es la diferencia entre ellos? En pocas palabras, podríamos decir que un modelo de dominio es un modelo general y simplificado de las "cosas" (las clases conceptuales) que integran un ambiente determinado, mientras que un modelo de negocio es un modelo interno de un negocio en particular que describe procesos y objetos (de negocio).
Lo que complica un poco el panorama es que muchas veces ambos términos se utilizan en forma intercambiable. No es un gran problema, porque clases conceptuales y entidades (u objetos de negocio) son prácticamente iguales: describen cosas o eventos importantes del área de estudio.
Como si fuera poco, el Unified Process (y sus variantes) plantea el desarrollo de un modelo de análisis (
http://sce.uhcl.edu/helm/RationalUnifiedProcess/) con el propósito de describir la realización de los casos de uso como colaboraciones entre clases de análisis. Estas clases, como ya hemos explicado en el capítulo 4, pueden ser de interfaz, de control o las llamadas
entidades.
¿Qué son las clases tipo entidad? Son las "cosas" que el sistema necesita manipular para poder cumplir con el comportamiento esperado. Usualmente, se derivan de las clases de dominio o de negocio (si se construyeron los respectivos modelos) o se identifican empleando una técnica similar a la empleada para encontrar a las primeras. La diferencia fundamental entre estas clases y las de los mencionados modelos es que éstas, además de propiedades (atributos) tienen responsabilidades (operaciones).
Hay otro término (un poco más antiguo) que también se emplea como sinónimo de modelo de dominio: el modelo de datos.
Como verán próximamente en el capítulo 6, a lo largo de los años se han identificado tres tipos o niveles de modelado de datos: el conceptual, que apunta a describir las entidades del dominio; el lógico, que describe el diseño de la base de datos que responde al modelo anterior (tablas, columnas, claves); y el físico, que detalla aspectos de implementación de la base de datos. Claramente, el primero de los niveles es equivalente al modelo de dominio o al de objetos de negocio.
¿Cuál de todos estos modelos construir? Bueno, dependerá de la situación.
Un ejemplo minimalista es el que nos propone Scott Ambler en su artículo
Agile/Evolutionary Data Modeling: From Domain Modeling to Physical Modeling (ver
http://agiledata.org/essays/agileDataModeling.html) Allí plantea un caso en donde un sistema a desarrollar se describe mediante un conjunto de
user stories y un modelo conceptual (aunque no nos dice cuáles son sus atributos). Luego se adentra en el diseño y describe cómo se obtiene la base de datos a partir del modelo conceptual.
Una alternativa para situaciones más complejas consiste en construir un modelo de dominio, un modelo de casos de uso y un modelo de análisis para los casos de uso más significativos. Las clases de análisis tipo entidad se derivarán de las clases conceptuales del modelo de dominio.
Quedará para nosotros decidir qué enfoque emplear.
Saludos,
El equipo de docentes
