¿Cuál es la relación entre DDD y la"Arquitectura Onion"?
¿Cuál es la relación entre Domain-driven design (DDD) y " The Onion Architecture" de Jeffrey Palermo?
3 answers
En mi opinión - se complementan entre sí - pero desde perspectivas muy diferentes.
La arquitectura Onion se trata de hacer que el Dominio/BusinessLogic sea independiente de cosas 'inferiores' como acceso a datos, interfaz de usuario, servicios, etc. A la Arquitectura Onion realmente no le importa cómo hiciste el dominio que tienes, es inflexible sobre protegerlo de dependencias externas.
El diseño basado en dominios tiene que ver con cómo modelas tu Dominio y lo que llamas tus objetos. Lo que significa que cada La clase de dominio debe tener una relación directa con lo que representa en el dominio de negocio que está dirigiendo (es decir. el mundo físico / real). Por lo tanto, un objeto Cliente debe llamarse Cliente en código: debe tener las mismas reglas que un Cliente en el mundo real (o lo más cerca posible).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-09-10 18:28:53
Si observa la imagen que describe la arquitectura onion en el enlace que proporcionó, la capa Domain Model es en lo que se enfoca DDD.
Onion es un patrón arquitectónico para un sistema, mientras que DDD es una forma de diseñar un subconjunto de los objetos en el sistema. Los dos pueden existir el uno sin el otro, por lo que ninguno es un subconjunto del otro. Si los usara juntos, entonces como un todo la parte que está diseñada usando DDD sería un subconjunto de todo el sistema.
A use una analogía (probablemente mala): La cebolla es un patrón para diseñar una casa, y el DDD es una forma de moler la madera que es una parte de la casa.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-08-03 19:35:27
Creo que los dos difieren entre sí en el "cómo diseñas y cuál es tu filosofía general" en el sistema en sí.
Con la arquitectura onion todo el mundo está alrededor de su almacén de datos. Esto significa que no te importa cómo "hacer el trabajo", pero te importa más en "quiero que el trabajo hecho". Obviamente, las mejores prácticas son (métodos pequeños, buenos nombres de variables, tal vez algunos patrones de diseño como Sigleton, etc. etc) todavía tienen un significado en este ámbito de vista, pero más para el código en sí y no tanto más para toda la visión general de la aplicación.
Por otro lado cuando hablamos de DDD hablamos de Negocio y cuando tomamos una decisión sobre la arquitectura siempre tenemos en mente el modelo de Negocio que queremos resolver. Y cuando digo decisión me refiero al total de las decisiones que un sistema puede tener(desde nombres de Variables / Clases / Funciones, hasta dónde colocamos una parte del código y al final del día cómo hablamos de este sistema en sí). Podríamos decir que un DDD es una " programación abstracción " del Modelo de Negocio). Pero por supuesto no podemos hacer DDD sin tener un negocio que resolver e.x no podemos hacer DDD en un programa como Shazam pero podemos hacer DDD en un programa como Facebook o Spotify.
Mi opción es que no se puede mezclar entre sí, sino que es la primera decisión.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-03-08 12:05:32