Cuándo aplicar y cuándo ignorar este tipo de arquitecturas

Cuando considerar arquitecturas limpias?

• Necesidad de mantenibilidad
• Testeabilidad. -> como que es difícil encontrar sistemas donde no sea muy necesario testear, dado que para desarrollar lo hacemos en base a requerimientos de un negocio y eso lo tenemos que validar.
• Múltiples integraciones (aislar el dominio de integraciones).
• Flexibilidad para cambiar implementación -> aquí me genera la duda sobre la diferencia con Mantenibilidad, me parece que estaría incluido en mantenibilidad (Open Close principle)

Cuando ignorar arquitecturas limpias?

• Sistemas sencillos ( ej: CRUD)
• PoC (Pruebas de concepto)
• Bajo # de integraciones ( ej: solo bd). -> Aquí también puede ser muy similar a sistemas sencillos.

En mi trabajo optaron por utilizar la poco famosa, pero más utilizada arquitectura “Big Ball of Mud” que básicamente significa que no usaron ninguna arquitectura de software e hicieron lo que se les dio la gana. Ahora que estoy implementando una tienda en línea, manipular los datos e integrarla con su ERP es un dolor de cabeza y un proceso supremamente ineficiente.

¿Cuándo aplicar arquitecturas limpias? 1. Sistemas que pueden crecer. 2. Necesidad de testeo permanente. 3. Sistemas que requieren múltiples integraciones 4. Sistemas que necesitan flexibilidad para cambiar implementaciones. ¿Cuándo no usar arquitecturas limpias? 1. Sistemas demasiado sencillos (CRUDS). 2. Pruebas de concepto, demostraciones. 3. Sistemas con tiempo de vida corto. 4. Sistemas con muy pocas o sin integraciones,.

¿En qué situaciones considerar arquitecturas limpias?

Sistemas donde la mantenibilidad es un atributo crucial

Es un sistema que existirá mucho tiempo o será manipulado por mucha personas, lo cual es esencial poder habilitar la posibilidad de realizar cambios dentro del software de manera sostenible.

Sistemas donde la testeabilidad es muy importante

Claro que todo debe ser testeable, pero hay contextos en donde la testeabilidad debe ser mucho más prolija y segura, como lo puede ser en proyectos bancarios o de salud.

Sistemas con múltiples integraciones

Si tenemos múltiples integraciones y que no nuestro dominio no se vea afectado por nuestras integraciones, una gran alternativa es utilizar arquitecturas limpias.

Flexibilidad para cambiar una implementación

Pueden haber dependencias inestables que en algún momento querramos cambiar, entonces, para proteger nuestro dominio podemos usar arquitectura limpia por la desacopable que es.

¿Cuándo ignorar arquitecturas limpias?

Claro que no sirven para todos los escenarios

Sistemas sencillos

Si hablamos de un simple CRUD, no tiene mucho beneficio mas que traer complejidad al mismo.

Sistemas con un tiempo de vida corto

Por ejemplo, una prueba de concepto o un proyecto MVP, ya que es muy posible que tal proyecto terminemoslo desechando o upgradearlo por uno mejor cuando las condiciones lo permitan.

Sistemas con ninguna o muy pocas integraciones

Si el sistema solo tiene una pura conexión a la base de datos y nada más, o nos relacionamos con solo una o dos aplicaciones, no es muy relevante utilizar arquitecturas limpias.

¿En qué situaciones considerar arquitecturas limpias?

• Sistemas donde la mantenibilidad es un atributo crucial
• Sistemas donde la testeabilidad es muy importante
• Sistemas con múltiples integraciones
• Flexibilidad para cambiar una implementación

¿Cuándo ignorar arquitecturas limpias?

• Sistemas sencillos
• Sistemas con un tiempo de vida corto
• Sistemas con ninguna o muy pocas integraciones

Solo aclarando algo, en el último punto el profesor dice que cuando hay pocas o ninguna integración en el software podríamos ignorar la opción de implementar una arq. limpia. Acá yo agregaría que “cuando no hay integraciones extra Y ADEMÁS se trata de un software sencillo o de vida corta podemos ignorar la idea de implementar alguna”. Lo comento porque uno pudiera pensar que si solo tenemos un monolito, no nos convendría implementar alguna clean arquitecture. Es decir, si nuestro software es un monolito, con pocas o ninguna integración, pero debe ser mantenible, entonces sí viene bien implementar alguna clean arquitecture 😃

✅

¿Cuándo aplicar y cuándo ignorar este tipo de arquitecturas?

¿Cuándo aplicarlas?

• Sistemas donde la mantenibilidad es un atributo crucial.
• Sistemas donde la testeabilidad es muy importante.
• Sistemas con múltiples integraciones.
• Flexibilidad para cambiar una implementación.

¿Cuándo ignorarlas?

• Sistemas sencillos, por ejemplo de un CRUD.
• Sistemas con un tiempo de vida corto, por ejemplo un POC o MVP.
• Sistemas con ninguna o muy pocas integraciones, por ejemplo una conexión a la base de datos o donde se integran con 1 o 2 aplicaciones.

He pasado por varios casos donde se ha ignorado usar una arquitectura limpia por puntos similares a los que comentas:

• Sistemas sencillos
• Sistemas con un tiempo de vida corto
• Sistemas con ninguna o muy pocas integraciones

Y más adelante nos han dado muchos dolores de cabeza para hacer un cambio de arquitectura y mantener el código.

Basicamente aunque estas arquitecturas prometan la nagging sensation que todo puede estar mejor y la queramos implementar el coste de implementación es bastante y muy posiblemente no valga la pena

Cuando veo que si se puede aplicar

Cuando queremos dejar de usar un codigo legacy donde tiene la lógica de negocio (Dominio) por todos lados regada y la aplicacion requiere conectarse de multiples servicios externos bases de datos, otras apis, message brokers en esos casos y cuando en el equipo hay ya muchas jergas y palabras que solo entiende el equipo si es bueno pasar eso que usualmente a algo mas tangible en el codigo como lo son los objectos de dominio. Otro factor clave creo que es la complejidad de la logica de negocio