¿Qué es el diseño impulsado por dominio?

¿Alguien puede explicar (en términos breves) qué es exactamente el diseño impulsado por dominio? Veo bastante el término, pero realmente no entiendo qué es o qué aspecto tiene. ¿Cómo difiere del diseño no dirigido por dominio?

Además, ¿alguien puede explicar qué es un objeto de dominio? ¿Cómo difiere el dominio de los objetos normales?

EDITAR:

Como este parece ser un resultado superior en Google y mi respuesta a continuación no lo es, consulte esta respuesta mucho mejor:

https://stackoverflow.com/a/1222488/1240557

ANTIGUA RESPUESTA (no tan completa :))

Para crear un buen software, debes saber de qué se trata ese software. No puede crear un sistema de software bancario a menos que comprenda bien de qué se trata la banca, uno debe comprender el dominio de la banca.

De: Diseño impulsado por dominio de Eric Evans.

Este libro hace un muy buen trabajo al describir DDD.

Regístrese para descargar un resumen del libro o descargue el resumen directamente .

Domain Driven Design es una metodología y prescripción de procesos para el desarrollo de sistemas complejos cuyo enfoque es mapear actividades, tareas, eventos y datos dentro de un dominio problemático en los artefactos tecnológicos de un dominio de solución.

El énfasis del diseño impulsado por dominio es comprender el dominio del problema para crear un modelo abstracto del dominio del problema que luego puede implementarse en un conjunto particular de tecnologías. El diseño impulsado por dominio como metodología proporciona pautas sobre cómo este desarrollo de modelo y desarrollo de tecnología puede dar como resultado un sistema que satisfaga las necesidades de las personas que lo utilizan y, al mismo tiempo, sea robusto frente al cambio en el dominio del problema.

El lado del proceso del diseño dirigido por el dominio implica la colaboración entre expertos en el dominio, personas que conocen el dominio del problema y los expertos en diseño / arquitectura, personas que conocen el dominio de la solución. La idea es tener un modelo compartido con un lenguaje compartido para que las personas de estos dos dominios diferentes con sus dos perspectivas diferentes discutan la solución, en realidad están discutiendo una base de conocimiento compartida con conceptos compartidos.

La falta de una comprensión del dominio del problema compartido entre las personas que necesitan un sistema en particular y las personas que están diseñando e implementando el sistema parece ser un impedimento central para proyectos exitosos. El diseño impulsado por dominio es una metodología para abordar este impedimento.

Es más que tener un modelo de objetos. El enfoque es realmente sobre la comunicación compartida y la mejora de la colaboración para que se puedan descubrir las necesidades reales dentro del dominio del problema y se cree una solución adecuada para satisfacer esas necesidades.

Diseño impulsado por dominio: lo bueno y lo desafiante proporciona una breve descripción general con este comentario:

DDD ayuda a descubrir la arquitectura de nivel superior e informar sobre la mecánica y la dinámica del dominio que el software necesita para replicarse. Concretamente, significa que un análisis DDD bien hecho minimiza los malentendidos entre los expertos en dominios y los arquitectos de software, y reduce el número subsiguiente de costosas solicitudes de cambio. Al dividir la complejidad del dominio en contextos más pequeños, DDD evita obligar a los arquitectos de proyectos a diseñar un modelo de objetos hinchados, que es donde se pierde mucho tiempo resolviendo los detalles de la implementación, en parte porque la cantidad de entidades con las que lidiar a menudo crece más allá de tamaño de las pizarras de la sala de conferencias.

Consulte también este artículo Diseño impulsado por dominio para la arquitectura de servicios que proporciona un breve ejemplo. El artículo proporciona la siguiente descripción en miniatura del diseño controlado por dominio.

Domain Driven Design aboga por el modelado basado en la realidad de los negocios como relevante para nuestros casos de uso. Como ahora se está volviendo más viejo y el nivel de exageración está disminuyendo, muchos de nosotros olvidamos que el enfoque DDD realmente ayuda a comprender el problema en cuestión y a diseñar el software hacia la comprensión común de la solución. Al crear aplicaciones, DDD habla de problemas como dominios y subdominios. Describe pasos / áreas de problemas independientes como contextos limitados, enfatiza un lenguaje común para hablar sobre estos problemas y agrega muchos conceptos técnicos, como entidades, objetos de valor y reglas raíz agregadas para apoyar la implementación.

Martin Fowler ha escrito una serie de artículos en los que se menciona el diseño impulsado por dominio como metodología. Por ejemplo, este artículo, BoundedContext , proporciona una descripción general del concepto de contexto acotado del Desarrollo dirigido por dominio.

En aquellos días más jóvenes, nos aconsejaron construir un modelo unificado de todo el negocio, pero DDD reconoce que hemos aprendido que "la unificación total del modelo de dominio para un sistema grande no será factible ni rentable" 1 . Entonces, en cambio, DDD divide un sistema grande en Contextos delimitados, cada uno de los cuales puede tener un modelo unificado, esencialmente una forma de estructurar Múltiples Modelos Canónicos.

Usted sólo puede entender el diseño de dominio impulsada por primera comprender lo que los siguientes son:

¿Qué es un dominio?

El campo para el que se construye un sistema. Gestión aeroportuaria, venta de seguros, cafeterías, vuelo orbital, lo que sea.

No es inusual que una aplicación abarque varios dominios diferentes. Por ejemplo, un sistema minorista en línea podría estar trabajando en los dominios de envío (eligiendo formas apropiadas de entrega, dependiendo de los artículos y el destino), precios (incluidas promociones y precios específicos del usuario por, por ejemplo, ubicación) y recomendaciones (cálculo relacionado productos por historial de compras).

¿Qué es un modelo?

"Una aproximación útil al problema en cuestión". - Gerry Sussman

Una clase de empleado no es un empleado real. Modela un verdadero empleado. Sabemos que el modelo no captura todo acerca de los empleados reales, y ese no es el punto. Solo pretende capturar lo que nos interesa para el contexto actual.

Diferentes dominios pueden estar interesados ​​en diferentes formas de modelar lo mismo. Por ejemplo, el departamento de salarios y el departamento de recursos humanos pueden modelar a los empleados de diferentes maneras.

¿Qué es un modelo de dominio?

Un modelo para un dominio.

¿Qué es el diseño controlado por dominio (DDD)?

Es un enfoque de desarrollo que valora profundamente el modelo de dominio y lo conecta con la implementación. DDD fue acuñado y desarrollado inicialmente por Eric Evans.

Sacado de aquí

Aquí hay otro buen artículo que puede consultar sobre Diseño impulsado por dominio . si su solicitud es algo más serio que una asignación universitaria. La premisa básica es estructurar todo alrededor de sus entidades y tener un modelo de dominio sólido. Diferenciar entre los servicios que proporcionan cosas relacionadas con la infraestructura (como enviar correos electrónicos, datos persistentes) y los servicios que realmente hacen cosas que son sus requisitos comerciales principales.

Espero que ayude.

Al igual que en TDD y BDD, usted / equipo se enfoca más en las pruebas y el comportamiento del sistema que en la implementación del código.

De manera similar cuando el analista del sistema, el propietario del producto, el equipo de desarrollo y, por supuesto, el código: entidades / clases, variables, funciones, procesos de interfaces de usuario se comunican usando el mismo lenguaje, se llama Diseño impulsado por dominio

DDD es un proceso de pensamiento. Al modelar un diseño de software, debe mantener el dominio / proceso empresarial en el centro de atención en lugar de las estructuras de datos, los flujos de datos, la tecnología, las dependencias internas y externas.

Hay muchos enfoques para modelar systerm usando DDD

• abastecimiento de eventos (uso de eventos como una única fuente de verdad)
• bases de datos relacionales
• bases de datos de gráficos
• usando lenguajes funcionales

Objeto de dominio:

En palabras muy ingenuas, un objeto que

• tiene un nombre basado en el proceso / flujo de negocios
• tiene control completo sobre su estado interno, es decir, expone métodos para manipular el estado.
• siempre cumpla con todas las reglas comerciales / invariantes comerciales en el contexto de su uso.
• sigue el principio de responsabilidad única

DDD (diseño impulsado por dominio) es un concepto útil para analizar los requisitos de un proyecto y manejar la complejidad de estos requisitos. Antes de que las personas estuvieran analizando estos requisitos al considerar las relaciones entre clases y tablas y, de hecho, su diseño se basaba en tablas de bases de datos relaciones no es viejo pero tiene algunos problemas:

• En proyectos grandes con requisitos complejos no es útil, aunque esta es una excelente forma de diseño para proyectos pequeños.

• Cuando no se trata de personas técnicas que no tienen un concepto técnico, este conflicto puede causar algunos problemas importantes en nuestro proyecto.

Por lo tanto, DDD maneja el primer problema al considerar el proyecto principal como un Dominio y dividir cada parte de este proyecto en piezas pequeñas que nos caracterizan por Contexto limitado y cada una de ellas no tiene influencia en otras piezas. Y el segundo problema se ha resuelto con un lenguaje omnipresente que es un lenguaje común entre los miembros del equipo técnico y los propietarios de productos que no son técnicos pero tienen suficiente conocimiento sobre sus requisitos.

En general, la definición simple de Dominio es el proyecto principal que genera dinero para los propietarios y otros equipos.

Creo que el siguiente pdf le dará una visión más amplia. Diseño impulsado por dominio por Eric Evans

NOTA: Piense en un proyecto en el que pueda trabajar, aplique las pequeñas cosas que entendió y vea las mejores prácticas. También le ayudará a aumentar su capacidad para el enfoque de diseño de arquitectura de micro servicios.

No quiero repetir las respuestas de los demás, así que, en resumen, explico algunos malentendidos comunes

• Recurso práctico: PATRONES, PRINCIPIOS Y PRÁCTICAS DEL DISEÑO IMPULSADO POR EL DOMINIO por Scott Millett
• Es una metodología para sistemas comerciales complicados. Elimina todas las cuestiones técnicas cuando se comunica con expertos empresariales.
• Proporciona una amplia comprensión del negocio (modelo simplificado y destilado) de todo el equipo de desarrollo.
• mantiene el modelo de negocio sincronizado con el modelo de código mediante el uso de un lenguaje ubicuo (el lenguaje entendido por todo el equipo de desarrollo, expertos en negocios, analistas de negocios, ...), que se utiliza para la comunicación dentro del equipo de desarrollo o el desarrollo con otros equipos
• No tiene nada que ver con la gestión de proyectos . Aunque puede usarse perfectamente en métodos de gestión de proyectos como Agile.

• Debe evitar usarlo en todo su proyecto

  DDD enfatiza la necesidad de concentrar el mayor esfuerzo en el subdominio central. El subdominio central es el área de su producto que será la diferencia entre ser un éxito y ser un fracaso. Es el punto de venta único del producto, la razón por la que se está construyendo en lugar de comprarlo.

  Básicamente, es porque lleva demasiado tiempo y esfuerzo. Por lo tanto, se sugiere dividir todo el dominio en subdominio y simplemente aplicarlo en aquellos con alto valor comercial. (ex no en subdominio genérico como correo electrónico, ...)

• No es programación orientada a objetos. Es principalmente un enfoque de resolución de problemas y (a veces ) no necesita usar patrones OO (como Gang of Four) en sus modelos de dominio. Simplemente porque no puede ser entendido por los expertos en negocios (no saben mucho sobre Factory, Decorator, ...). Incluso hay algunos patrones en DDD (como The Transaction Script, Table Module) que no están 100% en línea con los conceptos OO.