El diseño dirigido por dominios (con menos frecuencia diseño dirigido por dominios , DDD) es un conjunto de principios y esquemas destinados a crear sistemas óptimos de objetos. Se reduce a crear abstracciones de software llamadas modelos de dominio . Estos modelos incluyen una lógica de negocios que establece una conexión entre las condiciones reales del área de aplicación del producto y el código.
Domain-Driven Design no es una tecnología o metodología específica. DDD es un conjunto de reglas que le permiten tomar las decisiones de diseño correctas. Este enfoque le permite acelerar significativamente el proceso de diseño de software en un área temática desconocida.
El enfoque DDD es especialmente útil en situaciones donde el desarrollador no es un experto en el área del producto que se está desarrollando. Por ejemplo: un programador no puede conocer todas las áreas en las que se necesita crear software , pero con la representación correcta de la estructura, a través de un enfoque orientado al dominio, puede diseñar fácilmente una aplicación basada en puntos clave y conocimiento del área de trabajo. .
Este término fue introducido por primera vez por E. Evans en su libro del mismo nombre "Domain-Driven Design" [1] .
Idealmente, al diseñar, desea tener un solo modelo que describa completamente el área temática completa, pero en realidad, para simplificar el proceso de desarrollo del producto, el dominio se presenta como una combinación de varios modelos interrelacionados.
Un diagrama de arquitectura de aplicación es una descripción de uno o más modelos de dominio y sus relaciones entre sí.
Uso de varios modelos en varios niveles del proyecto . Este enfoque se utiliza para reducir las diversas relaciones entre modelos, lo que elimina la complejidad y las complejidades del código . A veces no está claro en qué contexto se debe utilizar el modelo.
Solución: Definir exactamente el contexto en el que se utiliza el modelo. Determinar los límites del uso de este modelo y sus características.
Cuando un gran número de personas trabajan en un proyecto, existe la tendencia a dividir el modelo en varios fragmentos más pequeños. Cuanta más gente, más significativo es este problema. En última instancia, se pierde la integridad del proyecto.
Solución: combinar constantemente piezas de código de diferentes desarrolladores y verificar la funcionalidad a través de pruebas . Esto permite que todos los desarrolladores permanezcan en un gran concepto.
Cuando se trabaja en varios modelos separados en un grupo grande, es posible que los diferentes miembros del equipo no sean conscientes de las entidades de otros modelos, lo que complica el proceso de ensamblaje general del producto final.
Solución: durante la fase de diseño, defina exactamente lo que hace cada modelo y cómo se relaciona con otros modelos. Al final, debe terminar con un mapa de relaciones modelo.
Cuando se diseña en base a un enfoque orientado al dominio, se utilizan los siguientes conceptos:
La mayoría de los sistemas para empresas utilizan áreas de responsabilidad a gran escala. En DDD, este nivel más alto de organización se denomina contexto acotado. Por ejemplo, el sistema de facturación de una gran empresa de telecomunicaciones puede tener los siguientes elementos clave:
Todos los elementos anteriores deben estar incluidos en un sistema único e ininterrumpido. Al diseñar, el sistema de notificación y el sistema de seguridad se destacan como cosas completamente diferentes. Los sistemas en los que la implementación falla en separar y aislar los contextos limitados a menudo adquieren un estilo arquitectónico que Brian Foot y Joseph Yoder llamaron acertadamente " Big Mudball " en 1999. [2]
La esencia del diseño de dominio específico es la definición específica de contextos y la restricción del modelado dentro de ellos.
La forma más fácil de expresar entidades es como sustantivos : personas, lugares, productos, etc. Las entidades tienen tanto una personalidad como un ciclo de vida. En el momento del diseño, debe pensar en las entidades como unidades de comportamiento en lugar de unidades de datos. La mayoría de las veces, alguna operación que está tratando de agregar al modelo debe ser recibida por alguna entidad, o se comienza a crear o recuperar una nueva entidad. En un código más débilmente acoplado , puede encontrar muchas clases de utilidad o de control que verifican las entidades desde el exterior.
Un objeto de valor es una propiedad que es importante en el dominio que está modelando. Ellos, a diferencia de las entidades, no tienen designación; simplemente describen entidades concretas que ya tienen designaciones. La utilidad de los objetos de valor es que describen las propiedades de las entidades de una manera mucho más elegante e intencional. Siempre vale la pena recordar que el valor de un objeto nunca cambia durante la ejecución de todo el código del programa . Una vez creada, no se pueden realizar modificaciones.
Un agregado es una entidad especial a la que acceden directamente los consumidores. El uso de agregados permite evitar una conexión excesiva de los objetos que componen el modelo. Esto evita confusiones y simplifica la estructura, porque no permite la creación de sistemas fuertemente acoplados.
A veces hay operaciones o procesos en un dominio que no tienen designación ni ciclo de vida. Los servicios de dominio proporcionan una herramienta para modelar estos conceptos. No tienen estado y están altamente acoplados, a menudo proporcionan un único método público y, a veces, una sobrecarga para las operaciones de conjuntos. Si se incluyen múltiples dependencias en un comportamiento y no hay forma de encontrar un lugar adecuado en la entidad para albergar ese comportamiento, entonces se usa un servicio. Aunque el término "servicio" en sí está sobrecargado con varios significados en el mundo del desarrollo, pero en este tema, significa una clase pequeña que no representa a una persona, lugar o cosa específica en la aplicación que se está diseñando, sino que incluye algún tipo de procesos. . El uso de servicios permite entrar en una arquitectura multicapa , así como integrar varios modelos, lo que introduce dependencia de la infraestructura. [3]
Aunque en concepto, el diseño orientado al dominio no debe limitarse a ninguna representación, en la práctica se utilizan las fortalezas de la programación orientada a objetos . Este es el uso de herencia , encapsulación , representación como métodos y clases. Debe recordarse que el enfoque de dominio específico se puede aplicar no solo a lenguajes OOP como Java , C# o C++ , sino también a lenguajes funcionales como F# , Erlang . Particularmente útiles son los lenguajes que admiten la creación y el uso de sus propios lenguajes específicos de dominio , como Scala (ver también LOP ).
| Desarrollo de software | |
|---|---|
| Proceso | |
Conceptos de alto nivel | |
| Direcciones |
|
| Metodologías de desarrollo | |
| Modelos |
|
Figuras notables |
|