Architecture Antipattern

Autor

Andreas Voigt — Principal Software Architect @ Adesso SE. LinkedIn

Que son los anti-patrones de arquitectura?

Consecuencias negativas de aplicar una solución, de la evolución de las arquitecturas, decisiones, contexto, negocio, la vida.

[!note] Charla relacionada: Architecture Antipatterns — Stefan Tilkov, GOTO Conference.

Antipattern: Emotional Attachment

Preferencia de una tecnología, una misma solución que ya se conoce, un lenguaje de programación o estar “casado” con una tecnología en particular.

Estar en una zona de confort y querer solucionar todo con las herramientas que ya conoces. A veces es conveniente, pero no siempre y puede traer problemas.

Una empresa de desarrollo de software para seguros desarrolló su propio middleware tipo CORBA que integraba un ORB, servicios DCOM y muchas más funciones.

Ventajas: tecnología propia, conocer los detalles, implementar soluciones custom.

Desventajas: costo elevado (no es parte del negocio), obsolescencia de la tecnología, transferencia de conocimiento dificil.

Ejemplo: DIY Middleware — Architecture Antipatterns

Anti-Patrón: Misapplied Genericity

Una solución muy genérica para ser usada para todo!! Termina siendo tan flexible que es compleja de desarrollar, usar, mejorar o corregir y a veces, no siendo utilizada por nadie.

Como evitar el problema de soluciones genéricas

Diseña para Casos de Uso Específicos 🎯
Mantén la Simplicidad — KISS (Keep It Simple, Stupid) 🧩
Itera y Refina Basado en Feedback 🔄

Caso de Estudio: APP financiera

-> hacer una app para todos los mercados, de varios países, termino siendo un problema muy complejo debido a que cada pais tiene sus procesos y leyes. Una APP generica, no resulto.

-> Solución BASE para mercados simples.

-> Solución CUSTOM para mercados complejos.

Anti-Patrón: Never change a running system 🚧

Sistemas legacy,
Algoritmos complejos,
Librerías de terceros, etc.
Lógica de negocio compleja (y si, sin documentación y todos los que conocían el negocio, ya no están!!!!)

Solución: escribir TEST, documentar lo que se pueda, hacer cambios muy chicos, tener una estrategia de rollback previa a aplicar los cambios.

Caso de Estudio: Document Management System BANCO.

Para estos casos: -> Automatizar pruebas, -> Documentar -> Reducir librerías -> Tener días de PATCH (patchdays)

Caso de Estudio: FAT client swing application

App vieja en java, 4 millones LOC, 15 años, etc.

Solución:

hacer pequeños Refactorings.
Actualizar librerias
Actualizar o armar “algo” de documentación
Test, test, test y si….TEST!!!

Tips

-> Test, importante -> Experimentar. -> documentar -> CI/CD armar pipelines. -> refactorings. -> evolutionary architecture.

Anti-Patrón: Cargo-Culting

Usar conceptos sin conocer el porque y como?

Usar el modelo de spotify. Si a ellos les funciona, seguro que aplica a todos!!!
Usar microservicios para todo (por que todos hablan de ello)
AI…y si, hay que usar AI, no importa para qué, usémoslo.

Otros Anti-Patrones

Domain Allergy. Enfocarse en la tecnología, el negocio es problema de otro.
Horizontalism: sistemas divididos en capas, donde cada una es responsabilidad de un equipo diferente.
Infrastructure Ignorance: ignorar la infraestructura donde se va a deployar el sistemas.
Malignant Growth: crecimiento sin control del sistema.
Over-Engineering: hacer lo simple, realmente complejo.