Domain-Driven Design (DDD ) es un conjunto de principios y pautas que
ayudan a los desarrolladores de sistemas de objetos artesanales elegantes. Aplica
correctamente puede llevar a abstracciones de software llamados modelos de
dominio. Estos modelos encapsulan lógica de negocio compleja, cerrando la
brecha entre la realidad empresarial y el código. [1]
El
concepto más importante en DDD es centrarse en el dominio del problema. Para poner obsesión tecnología a un lado y centrarse
principalmente en la modelización del problema que estamos tratando de
resolver. Así que ponga ajax, ORM, bases de datos, los
marcos etc en el fondo y en su lugar asegúrese de que tiene un modelo completo
y preciso del problema en primer lugar. (Por supuesto, usted todavía
tiene los componentes de la arquitectura - pero son explícitamente subordinada
al modelo). DDD llama a esto "Ubiquitous
Language" - un modelo expresado en términos expertos de dominio y desarrolladores
por igual usar y entender. Un modelo en el que los nombres
de las clases, métodos, etc se toman del dominio del problema.[2]
DDD
no ordena / la forma / de capturar ese modelo, aunque el libro implica el uso
de un lenguaje orientado a hacerlo.
Acciones
MDA esa misma idea de modelar el dominio del problema en primer lugar (el,
modelo de la plataforma indepdent PIM). A diferencia de DDD, recomienda la creación de ese modelo con UML. Pero la intención es la misma: entender el dominio del problema y
sin contaminar con (software) se refiere a la arquitectura.
PSM
de la MDA (modelo específico de la plataforma) es algo análogo a la aplicación
de los patrones arquitectónicos en DDD (por ejemplo, agregada, repositorio,
etc). Una vez más - aunque diferentes
en detalles - tanto objetivo de resolver el problema de la conversión de un
modelo de dominio del problema "puro" en un sistema de software
completo.
Así
que resumiendo, yo diría que son similares en dos formas:
1. La
centralidad de la Modelo específicamente el / Dominio / modelo.
2. La
aplicación de patrones de arquitectura del modelo para realizar el sistema de
destino.
Domain-Driven Design , tiene una
serie de conceptos y prácticas de alto nivel, se articulan, como en
todas partes idioma lo que
significa que el modelo de dominio debe formar un lenguaje
común dada por los
expertos de dominio para la descripción de los requisitos del sistema, que
funciona igual de bien para los usuarios de negocios o patrocinadores y para
los desarrolladores de software. [3]
En la última
década o dos, la filosofía se ha desarrollado como una corriente subterránea en
la comunidad objeto. La premisa de Domain-Driven Design es doble:[4]
·
Para la mayoría de los
proyectos de software, el enfoque principal debe estar en la lógica de dominio
y el dominio, y
·
Diseños dominio complejo deben
basarse en un modelo.
Desconocido. (26 de Junio de 2007). DDDCommunity.
Recuperado el 21 de Noviembre de 2013, de DDDCommunity:
http://dddcommunity.org/
Desconocido. (Mayo de 2009). Wikipedia.
Recuperado el 21 de Novimbre de 2013, de Wikipedia:
http://en.wikipedia.org/wiki/Domain-driven_design
Laribee, D. (s.f.).
Microsoft. Recuperado el 21 de
Noviembre de 2013, de Microsoft:
http://msdn.microsoft.com/en-us/magazine/dd419654.aspx
sfinnie. (12 de Noviembre de 2010). stackoverflow.
Recuperado el 21 de Noviembre de 2013, de stackoverflow:
http://stackoverflow.com/questions/4166816/domain-driven-design-vs-model-driven-architecture
No hay comentarios:
Publicar un comentario