Architecture Antipattern

)

Autor

Andreas Voigt — Principal Software Architect @ Adesso SE. LinkedIn

Que son los anti-patrones de arquitectura?

flowchart TD
    AP["⚠️ Architecture Antipatterns\n(consecuencias negativas de\ndecisiones de diseño)"]

    AP --> EA["❤️ Emotional Attachment\nUsar siempre la misma\ntecnología (zona de confort)"]
    AP --> MG["🔧 Misapplied Genericity\nSolución genérica para todo\n→ complejidad innecesaria"]
    AP --> NCTS["🚧 Never Change\na Running System\nSistemas legacy bloqueados"]
    AP --> CC["🦜 Cargo-Culting\nCopiar sin entender\n(Spotify model, microservices, AI)"]
    AP --> OT["🔢 Otros"]

    OT --> DA["Domain Allergy"]
    OT --> HZ["Horizontalism"]
    OT --> II["Infrastructure Ignorance"]
    OT --> MG2["Malignant Growth"]
    OT --> OE["Over-Engineering"]

    EA -->|"solución"| SOL["✅ KISS + Tests +\nDocumentación +\nCI/CD + Refactoring"]
    MG --> SOL
    NCTS --> SOL
    CC --> SOL

    style AP fill:#1e1e2e,stroke:#ff5555,color:#f8f8f2
    style SOL fill:#1e1e2e,stroke:#50fa7b,color:#f8f8f2

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.