DOMAIN MODEL

Cuando se empieza a construir una aplicación (distribuida). . . necesitamos una estructura inicial para el software que se está desarrollando.

✦✦✦

Los requisitos y las restricciones informan la funcionalidad, calidad del servicio, y aspectos de desarrollo del sistema software, pero no sugieren la estructura concreta que dirija el desarrollo. Sin una visión precisa y razonada en el alcance de un sistema y su dominio de aplicación, no obstante, su realización se puede convertir en una gran bola de barro que será difícil de entender y transmitir a los clientes, y una pobre base arquitectónica sobre la que se pueda construir.  

Una lista de requerimientos muestra el dominio del problema de una aplicación, pero no es el dominio de la solución. Sin embargo, los requerimientos de un sistema debe ser dirigidas por las entidades concretas de software. Si las entidades y sus interacciones están relacionadas con la principal aplicación del negocio, sin embargo, va a ser difícil de comprender y comunicar lo que el sistema realmente hace. Del mismo modo, será difícil cumplir con la calidad de los requerimientos de servicio, ya que no se pueden asignar claramente a los elementos de software cuando sean pertinentes. Sin una visión clara del dominio de aplicación de un sistema, por lo tanto, los arquitectos de software no puede determinar si sus diseños son correctos, completos, coherentes y lo suficientemente acotado para servir como la base para el desarrollo.

Crear un modelo que define las responsabilidades y alcances de un sistema de negocio y sus variaciones: los elementos del modelo son abstracciones significativas en el dominio de aplicación, mientras que sus roles e interacciones reflejan el flujo de trabajo del dominio.

El modelo de dominio es la base para la arquitectura software de un sistema, que se convertirá en una expresión del modelo a medida que evoluciona.

✦✦✦

Un modelo de dominio constituye el paso inicial en la transformación de los requerimientos en una arquitectura software sostenible y la implementación. La definición de un modelo preciso para la estructura y el flujo de trabajo de un dominio de aplicación, incluyendo sus variantes, ayuda a trazar los requisitos para las entidades de software concretos y comprobar si los requisitos están completos y consistente. Los requisitos que no puede ser identificado, los requisitos confusos, y los requisitos innecesarios son eliminados. Como resultado, las responsabilidades y los límites de la arquitectura de un sistema están en el ámbito correcto. Un modelo de dominio bien formado también hace que sea más fácil cumplir con la calidad de un sistema de requisitos de servicio, debido a que pueden ser asignados a los elementos específicos y flujos de trabajo a que se aplican en el modelo. Un modelo de dominio también fomenta la comunicación entre los profesionales de software, expertos de dominio y clientes, debido a que sus elementos se basan en la terminología utilizada en el dominio de aplicación.

Una vez que el modelo de dominio ha madurado hasta el punto en el que retrata adecuadamente las responsabilidades funcionales de una aplicación, así como sus variaciones, el siguiente paso es transformar el modelo en una arquitectura concreta que se expresa y que soporta esta funcionalidad, que aborda los requisitos de calidad del servicio, tales como el rendimiento, la escalabilidad, disponibilidad, adaptabilidad y capacidad de ampliación. Varios patrones ayudan a organizar y conectar los elementos de un dominio del modelo para apoyar a estilos específicos de cálculo. Por ejemplo:

PIPES AND FILTERS (200) es adecuado para aplicaciones que procesan flujos de datos, SHARED REPOSITORY (202) ayuda a organizar aplicaciones data-driven y BLACKBOARD (205) es adecuado para aplicaciones que trabajan con datos incompletos, o para algoritmos de soluciones no determinísticas...