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.
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 .
¿Es “Clean Architecture” de Bob Martin una regla general para todas las arquitecturas o es solo una de las opciones?
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.
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. Los marcos (web, android, etc.) deben ser complementos que se conectan a la lógica empresarial. Incluso se burla sutilmente de los rieles en el video.
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.