architecture - La cebolla contra la arquitectura de N capas
dependency-injection inversion-of-control (4)
Una cosa de antemano: llego de un fondo de N capas.
Ahora he dedicado bastante tiempo a familiarizarme con conceptos de Onion Architecture y Domain Driven relacionados, como los recursos de lectura de Hexagonal Architecture, como la serie de publicaciones de blog de Jeff Palermo , la contribución de Mark Seemann desde una perspectiva DI , "Onion-izing your achitecture" , y "La arquitectura limpia" .
Lo que todos estos artículos tienen en común es que afirman los siguientes puntos:
- El enfoque se mantiene alrededor del modelo de dominio del caso de uso empresarial.
- Acoplamiento más suelto entre capas al enfatizar el principio de inversión de dependencia
- Mayor independencia de las infraestructuras externas, como marcos, persistencia de datos, IU
- Mejor testabilidad / mantenibilidad
Bueno, todo eso suena increíblemente bonito y esos diagramas también se ven dulces. Pero la pregunta que me surge es: ¿no se logra todo eso simplemente añadiendo fachadas a mi arquitectura tradicional de N capas?
- Cada capa solo conoce las abstracciones de la capa de abajo
- Las implementaciones concretas se pueden mantener internas a cada capa y, por lo tanto, están en el mismo lugar que las abstracciones.
- Los detalles de la implementación se pueden intercambiar fácilmente ya que son internos a la capa y no deben afectar al resto de la aplicación
Por favor, ayúdeme a comprender las verdaderas ventajas de una arquitectura centrada en el dominio.
¡Gracias por adelantado!
Agregar fachadas es realmente el primer paso para construir una arquitectura de cebolla a partir de una arquitectura de n capas. Entonces, sí, puede obtener muchos de los beneficios de inmediato.
Las pruebas siguen siendo problemáticas ya que necesita invertir el control de dependencia. El control de lo que tiene la fachada apunta a las necesidades para trasladarse al consumidor, no al proveedor. Esto permite al consumidor intercambiar cosas para realizar pruebas o cambiar las implementaciones sin que el proveedor tenga que saberlo.
Aunque es una pregunta muy antigua, pero me gustaría añadir algo.
Este artículo lo explica claramente por qué las capas no son preferibles, pero si implementó IOC correctamente, no habrá ninguna diferencia.
Estoy compartiendo la misma opinión que la tuya. Estamos planeando lanzar un nuevo proyecto y uno de mis compañeros de trabajo sugirió la arquitectura de la cebolla, pero después de documentar un poco al respecto, estaba un poco confundido, porque (¡para mí!) el hecho de que cada capa de cliente debe depender solo de la abstracción de la capa utilizada es una cuestión de la mejor práctica que siempre se debe tener en cuenta independientemente de la arquitectura que planeamos usar, DI es un "Principio", no una arquitectura, por lo que no puedo ¿Se da cuenta de que el uso de la arquitectura N-Layered con "buenos principios OO" la convierte en una nueva arquitectura?
De esta manera, terminaremos con cientos de arquitecturas nuevas simplemente combinando todos los OO Principals y los patrones Go4 con las arquitecturas de aplicaciones de Entreprise.
Para abordar su pregunta directamente "¿No se logra todo eso simplemente añadiendo fachadas a mi arquitectura tradicional de N capas?". La respuesta es sí, y no, dependiendo de su caso de uso.
El enfoque de la arquitectura de Onion en el uso de la inversión de dependencia es como usted dijo ... "crear un acoplamiento más flexible". Sin embargo, no es solo por el bien del acoplamiento perdedor. Podría ayudar a pensar que es "proteger las partes de su código que tienen menos probabilidades de cambiar, de las partes que tienen más probabilidades de cambiar". Entonces, para su caso, ¿los cambios "debajo" de la fachada requerirán cambios en su código de "dominio"? ¿Un cambio a, digamos, un objeto de base de datos, gotearía en cambios a un objeto usado en la fachada y luego en su código de "dominio"? Si la respuesta a este tipo de preguntas es "no", su suposición es correcta, no hay una diferencia funcional significativa para ese código. Si alguien contestara "tal vez", entonces podría beneficiarse de la refactorización de las fachadas al COI.