Realmente me gustaron los conceptos en el video Los principios de la arquitectura limpia del tío Bob Martin . Pero siento que este patrón es como una combinación de patrones Abstract Factory y Builder en su núcleo.
Esta es una forma de escribir buenos programas, pero no la única.
Rails y reactjs son 2 marcos que vienen a la mente que no promueven este tipo de arquitectura limpia. Rails espera que su lógica de negocios esté en los modelos ( FatModels y SkinnyControllers ) y reaccione dentro de sus componentes. Ambos enfoques combinan estrechamente la lógica empresarial y el código marco .
No encuentro nada malo en ninguna de las 3 formas. Es una decisión judicial elegir a cualquiera.
Pero en el video creo que sugiere que la arquitectura limpia debería tener un límite claro entre la lógica de negocios y los marcos. Marcos (web, androide, etc.) deben ser los plugins que se conectan a la lógica de negocio. Incluso se burla sutilmente de los rieles en el video.
Entonces, ¿es "Clean Architecture" de Bob Martin una regla general para todas las arquitecturas o es solo una de las opciones?
fuente
Respuestas:
Si bien la “Arquitectura limpia” está bien y tiene muchas ventajas, es importante recordar que:
La arquitectura limpia es en gran parte el cambio de marca y la evolución de enfoques relacionados de Robert C. Martin como la Arquitectura de cebolla de Jeffrey Palermo (2008) y la Arquitectura hexagonal ("Puertos y adaptadores") de Alistair Cockburn y otros (<2008).
Diferentes problemas tienen diferentes requisitos. La arquitectura limpia y los enfoques relacionados convierten el desacoplamiento, la flexibilidad y la inversión de dependencia en once, pero sacrifican la simplicidad. Esto no siempre es un buen negocio.
El precursor de estas arquitecturas es el patrón clásico MVC de Smalltalk. Esto desenreda el modelo de la interfaz de usuario (controlador y vista), de modo que el modelo no depende de la interfaz de usuario. Hay muchas variaciones de MVC como MVP, MVVM, ...
Los sistemas más complejos no tienen una sola interfaz de usuario, sino posiblemente múltiples interfaces de usuario. Muchas aplicaciones optan por ofrecer una API REST que puede ser consumida por cualquier interfaz de usuario, como una aplicación web o una aplicación móvil. Esto aísla la lógica empresarial en el servidor de estas IU, por lo que al servidor no le importa qué tipo de aplicación accede a ella.
Por lo general, el servidor todavía depende de servicios de fondo como bases de datos o proveedores de terceros. Esto está perfectamente bien y conduce a una arquitectura simple en capas.
La arquitectura hexagonal va más allá y deja de hacer una distinción entre frontend y backend. Cualquier sistema externo puede ser una entrada (fuente de datos) o una salida. Nuestro sistema central define las interfaces necesarias (puertos) y creamos adaptadores para cualquier sistema externo.
Un enfoque clásico para un desacoplamiento fuerte es una arquitectura orientada a servicios (SOA), donde todos los servicios publican eventos y consumen eventos desde un bus de mensajes compartido. Un enfoque similar fue popularizado más tarde por los microservicios.
Todos estos enfoques tienen ventajas , como facilitar la prueba del sistema de forma aislada (al reemplazar todos los sistemas externos con los que interactúa por implementaciones simuladas). Hacen que sea más fácil proporcionar implementaciones múltiples para un tipo de servicio (por ejemplo, agregar un segundo procesador de pagos), o cambiar la implementación de un servicio (por ejemplo, pasar de una base de datos de Oracle a PostgreSQL, o reescribiendo un servicio de Python en Go) .
Pero estas arquitecturas son el Ferrari de las arquitecturas: caras y la mayoría de las personas no las necesitan. La flexibilidad adicional de la Arquitectura limpia, etc. tiene el costo de una mayor complejidad. Muchas aplicaciones y especialmente las aplicaciones web CRUD no se benefician de eso. Tiene sentido aislar cosas que pueden cambiar, por ejemplo, mediante el uso de plantillas para generar HTML. Tiene menos sentido aislar cosas que es poco probable que cambien, por ejemplo, la base de datos de respaldo. Lo que es probable que cambie depende del contexto y las necesidades comerciales.
Los marcos hacen suposiciones sobre lo que va a cambiar. Por ejemplo, React tiende a suponer que el diseño y el comportamiento de un componente cambian juntos, por lo que no tiene sentido separarlos. Pocos marcos suponen que es posible que desee cambiar el marco. Como tal, los marcos presentan una cantidad de bloqueo. Por ejemplo, la confianza de Rail en el patrón de registro activo (¡muy obstinado!) Hace que sea difícil o imposible cambiar su estrategia de acceso a datos al patrón de repositorio (a menudo superior). Si sus expectativas de cambio no coinciden con el marco, utilizar un marco diferente podría ser mejor. Muchos otros marcos web no hacen suposiciones sobre el acceso a datos.
fuente
Ni siquiera cerca.
Cuando miras esto:
Estás mirando el diseño de un gráfico de objeto. Esto dicta lo que sabe sobre qué. Lo que falta en esta historia es cómo se construyó ese gráfico de objeto. Lo siento pero no encontrarás eso aquí. No hay ninguna mención de construcción.
Puedes construir todo esto sin fábricas abstractas y constructores. Lo sé porque lo hice . Ni siquiera me propuse evitarlos. Los amo. Simplemente no los necesitaba. Acabo de usar el paso de referencia. La inyección de dependencia es el término elegante para eso.
De hecho, podría construir todo lo que ves en ese diagrama en main. Luego solo llame a un método en un objeto para comenzar a marcar todo.
Ahora las cosas tienen que existir antes de poder empujarlas a otras cosas. Exploré eso aquí y le di este pequeño y lindo diagrama:
Y puedes construir todo eso sin siquiera irte
main().Recomendaría usar constructores y fábricas cuando desee dividir un montón de código de construcción de procedimientos en trozos conceptuales de buen tamaño. Pero no hay nada en la arquitectura limpia o en ninguna de las otras arquitecturas de palabras de moda que exija que lo haga. Entonces, si quieres seguir
main(), bien. Solo por favor, ten piedad .Considero que Clean Architecture es una palabra de moda utilizada para atraer a las personas a un blog y un libro. Ese blog y libro tienen muy buenas explicaciones de arquitecturas antiguas muy similares con nombres antiguos utilizados para atraer a las personas a blogs y libros antiguos. Específicamente cebolla, así como puertos y adaptadores. Ninguna de las cuales son las únicas opciones arquitectónicas que tiene.
Me gusta el tío Bob porque es un increíble orador y autor público. Me hace pensar en cosas que de otro modo no tendría. Pero si dejas que eso te convierta en un fanático religioso que insiste en que todo debe hacerse a su manera, rápidamente encontrarás que actualizar la documentación es lo más cerca que te dejaré llegar a mi código.
Las arquitecturas de palabras de moda son útiles cuando tiene un código de larga duración que debe persistir mientras el mundo cambia a su alrededor. Ahí es cuando brilla. Si el mundo es estable en comparación con el código, entonces estás haciendo las cosas elegantes sin una buena razón.
No importa cuán increíble parezca algo, hay un contexto en el que puedes ponerlo que lo hará absurdo. Lo siento, esto tampoco es una bala de plata.
Tienes razón. Lo hace. El tío Bob siente que los marcos pueden ser tratados como bibliotecas. Y ellos pueden. Pero incluso esa decisión te cuesta algo.
Lo que el Sr. Martin está tratando de preservar es un espacio donde su lenguaje de propósito general es general. Lo abandonas cuando difundes un marco por todas partes. Cuando haces eso, te diriges por el camino de transformar tu idioma en algo llamado lenguaje específico de dominio. HTML es un lenguaje específico de dominio. Hace su trabajo muy bien, pero hay otros trabajos que no puede hacer en absoluto.
Mientras el marco de trabajo prevea sus necesidades, todo irá bien. Es bueno tener sus necesidades anticipadas. Te pone en una caja que simplifica las cosas. Solo entiende lo que estás renunciando para conseguir esto. Si difunde Spring en todas partes, ya no podrá anunciarlo como un trabajo Java. Es un trabajo de Java / Spring. Podría decir lo mismo sobre Ruby y Rails, pero Rails comió el almuerzo de Ruby hace mucho tiempo.
fuente
Para citar el video:
seguido por:
La arquitectura, como las combinaciones de correspondencia, es solo una opción entre muchas.
Lo que no es opcional son los problemas que la arquitectura está tratando de resolver.
Si comprende qué problemas causa la combinación de correspondencia SQL frente a otras soluciones, su elección arquitectónica será informada e incluso si se ve obligado a elegir soluciones 'malas', estará al tanto y mitigará sus deficiencias.
Si sigues un estilo arquitectónico solo porque está bien pensado, entonces es probable que cometas errores y encuentres los mismos problemas.
fuente
"Arquitectura limpia" es definitivamente "solo" una de las opciones. Yo diría que es una de las malas opciones para la mayoría de los proyectos, especialmente para proyectos orientados a objetos.
Aquí hay un análisis de oración por oración del artículo del tío Bob sobre arquitectura limpia con las razones de la declaración anterior:
La arquitectura limpia desde una perspectiva orientada a objetos
fuente
Clean Architecture es un conjunto de principios y patrones para abordar una serie de síntomas comunes que las organizaciones de desarrollo de software a menudo enfrentan durante la vida útil de la creación de aplicaciones complejas. El Sr. Martin hace todo lo posible en el libro para identificar los síntomas y las causas fundamentales en base a su amplia experiencia en el campo, y para aclarar el papel de la arquitectura en la mitigación de estas preocupaciones.
Sin embargo, no es una regla de oro, ni una panacea para todos los males. Si lees el libro, comprenderás mejor si / cuándo / cómo aplicar los principios y patrones que defiende (y las compensaciones involucradas). Si no ha leído el libro, es probable que haga suposiciones, solicitudes, juicios y declaraciones incorrectas basadas en información incompleta.
fuente