language-agnostic - sobre - series de netflix pdf
Diseño impulsado por el dominio frente a la arquitectura impulsada por el modelo (3)
DDD se trata de abordar una solución de software desde una perspectiva comercial con la intención de mantener el diseño lo más cercano posible al mundo real. Esto es más un arte que ingeniería.
MDA resuelve diferentes problemas. Más detalles aquí: http://xml.coverpages.org/OMG-MDAFAQfinal1.pdf
Tengo curiosidad, ¿cuáles son las diferencias entre Domain Driven Design y Model Driven Architecture? Tengo la impresión de que tienen ciertas similitudes.
¿Podrías iluminarme?
Gracias
La raíz del Diseño Controlado por Dominio (DDD) y la Arquitectura Dirigida por Modelo (MDA) es Ingeniería Dirigida por Modelo (MDE), también conocida como Desarrollo de Software Dirigido por Modelo (MDSD) si está limitada al dominio de desarrollo de software. Ver Wikipedia: http://en.wikipedia.org/wiki/Model-driven_development
Todos los enfoques que caen bajo el paraguas de MDE tienen una cosa en común: un modelo. Cómo se materializa este modelo depende del sabor MDE específico.
La MDA es considerada como demasiado compleja. DDD es considerado por algunos como demasiado abstracto. Mis implementaciones de MDE favoritas personales son DSM y ABSE (no figuran en el artículo de Wikipedia).
No esté en desacuerdo con la mayoría de las anteriores, aunque tal vez valga la pena expandirse un poco.
El concepto más importante en DDD es centrarse en el dominio del problema. Poner la obsesión de la tecnología a un lado y concentrarse principalmente en modelar el problema que estás tratando de resolver. Así que pon a un lado los ajax, los ORM, las bases de datos, los marcos, etc. en su lugar y asegúrate primero de tener un modelo completo y preciso del problema. (Por supuesto, todavía necesita los componentes arquitectónicos, pero están subordinados explícitamente al modelo). DDD llama a esto "Lenguaje ubicuo", un modelo expresado en términos que los expertos en el dominio y los desarrolladores usan y entienden por igual. Un modelo donde los nombres de clases, métodos, etc. se toman del dominio del problema.
DDD no ordena / cómo / captura ese modelo, aunque el libro implica usar un lenguaje OO para hacerlo.
MDA comparte esa misma noción de modelar el dominio del problema en primer lugar (el PIM, modelo independiente de la plataforma). A diferencia de DDD, recomienda crear ese modelo con UML. Pero la intención es la misma: comprender el dominio del problema sin mancharlo con preocupaciones arquitectónicas (de software).
El PSM (Modelo específico de plataforma) de MDA es similar a la aplicación de los patrones arquitectónicos en DDD (por ejemplo, agregado, repositorio, etc.). De nuevo, aunque diferentes en detalles, ambos intentan resolver el problema de convertir un modelo de dominio de problema "puro" en un sistema de software completo.
Para resumir, diría que son similares de dos maneras:
- La centralidad del modelo (como dice @Rui) - específicamente el / dominio / modelo.
- Aplicando patrones arquitectónicos al modelo para realizar el sistema objetivo.
hth.