Software Architecture
Reúne antipatrones como arquitectura por moda, monolito distribuido, base compartida, capas ceremoniales, shared kernel indiscriminado y abstracciones filtrantes.
Un antipatrón no es una tecnología prohibida. Es una solución o estructura recurrente que parece útil en cierto momento, pero produce consecuencias negativas previsibles cuando se aplica fuera de contexto o se deja crecer sin control.
Los antipatrones se diagnostican por sus causas y efectos, no por nombres llamativos.
presión o decisión inicial
→ estructura repetida
→ beneficio inmediato
→ costo acumulado
→ síntomas observables
→ intervenciónMicroservicios, una base compartida o una abstracción no son antipatrones por sí mismos. Se convierten en problema cuando contradicen drivers, ownership o capacidad operativa.
La corrección tampoco consiste en aplicar el patrón opuesto. Un Big Ball of Mud no se arregla automáticamente separándolo en cincuenta servicios; puede transformarse en un Distributed Monolith más costoso.
Para cada síntoma pregunta:
Un sistema donde responsabilidades, dependencias y ownership no pueden reconocerse con claridad. Cualquier parte puede conocer o modificar cualquier otra.
El lead time crece, el miedo a cambiar aumenta y cada nueva persona aprende excepciones en lugar de un modelo mental.
No intentes “limpiar todo”.
Un conjunto de servicios desplegados por separado, pero acoplados de forma que deben desarrollarse, probarse o desplegarse juntos.
servicio A → B → C → D
↘ base compartida ↙Se pagan red, observabilidad, pipelines y fallos parciales sin obtener autonomía.
Volver a un monolito modular puede ser una mejora, no un fracaso.
Un componente central que conoce y coordina demasiadas capacidades.
Ejemplos:
ApplicationService con cientos de métodos.settings que controla toda la aplicación.Clasifica responsabilidades por razón de cambio. Extrae capacidades con modelo y datos propios. Mantén un orquestador solo cuando el flujo realmente necesita coordinación; no debe poseer reglas de cada participante.
Múltiples módulos o servicios utilizan las mismas tablas como contrato de integración, especialmente si todos pueden escribirlas.
Una base compartida dentro de un monolito no es incorrecta. El antipatrón es ownership implícito o múltiple.
Una interacción necesita muchas llamadas pequeñas para completar una intención.
getOrder
→ getCustomer
→ getItems
→ getInventory por item
→ getPrice por itemDiseña operaciones por intención o vistas agregadas. Usa batching, composición o proyecciones cuando corresponda. No muevas simplemente las mismas llamadas a GraphQL sin resolver ownership y costo.
Componentes deben ejecutarse en un orden o momento específico aunque el contrato no lo hace explícito.
Ejemplo:
crear usuario
→ esperar 2 segundos
→ consultar perfil
→ iniciar configuraciónModela estados, eventos, confirmaciones o workflows. Haz visible cuándo una operación está pending, completed o failed.
Varias capas reintentan una dependencia degradada y multiplican la carga.
cliente 3 intentos
× gateway 3
× servicio 3
= hasta 27 llamadasUna degradación parcial se convierte en colapso.
Aumentar timeouts suele retrasar el colapso, no resolverlo.
Aplicar la tecnología conocida a problemas diferentes porque el equipo domina esa herramienta.
Ejemplos:
La justificación describe la herramienta, no el problema. No se comparan alternativas ni trade-offs.
Volver a drivers, ejecutar spikes y permitir un conjunto tecnológico pequeño pero no dogmático.
Copiar prácticas de otra organización sin copiar su contexto, escala, equipos ni capacidades.
Ejemplos:
Ceremonia, operación y vocabulario que no compran una capacidad real.
Para cada patrón exige:
Una interfaz pretende ocultar un mecanismo, pero los consumidores necesitan conocer sus detalles.
Ejemplo:
paymentPort.charge({
stripePaymentMethodId,
stripeConnectedAccount,
});Aunque se llame PaymentPort, el dominio depende del proveedor.
Modelar conceptos del dominio, traducir en adapters y reconocer capacidades no portables. Una abstracción honesta no promete reemplazo gratuito.
El sistema publica eventos sin ownership, schemas ni garantías, y termina usando el broker como base de datos informal.
DataUpdated.Objetos de dominio solo contienen datos y todas las reglas viven en servicios procedurales.
No todo CRUD necesita un modelo rico. El antipatrón aparece cuando existen invariantes importantes y se duplican fuera de la entidad o agregado.
Mover invariantes y transiciones al modelo que posee el estado. Mantener orquestación externa y mecanismos fuera.
Diseñar abstracciones y extensibilidad para futuros hipotéticos sin evidencia.
Más navegación, bugs y mantenimiento hoy; el futuro real puede necesitar otra abstracción.
Diseñar para cambio probable y preservar seams. Elegir decisiones reversibles. Introducir generalización después de observar variación real.
El opuesto también existe: ignorar riesgos conocidos por “mantenerlo simple”.
Ejemplos:
La simplicidad debe ser suficiente para los drivers, no ausencia de diseño.
Separar procesos antes de necesitar independencia de despliegue, escala o ownership.
Se introducen red, consistencia eventual, observabilidad y operación.
Fortalecer módulos dentro del proceso y extraer cuando existan señales reales.
Adoptar una dependencia estratégica sin comprender datos, semántica, precio y salida.
Contrato propio donde aporte valor, due diligence, observabilidad, triggers y estrategia de migración.
Recolectar logs y dashboards sin capacidad de responder preguntas operativas.
Empezar por journeys y preguntas: impacto, tenant, dependencia, estado y acción. Diseñar SLI, trazas y runbooks.
Concentrar autenticación o validación en gateway y asumir que el tráfico interno es confiable.
Una ruta interna, job o componente comprometido puede saltarse controles.
Defensa en profundidad: identidad, autorización en la capacidad, scope de datos, permisos y auditoría.
Construye evidencia:
Después conecta síntoma con causa. Un endpoint lento puede deberse a chatty interface, query sin índice, cola o proveedor; “añadir caché” sin diagnóstico puede introducir otro problema.
Síntoma: confirmar una venta requiere llamadas a Pedidos, Inventario, Precios, Clientes y Notificaciones.
Posibles causas:
Intervención:
No se corrige añadiendo retries a todas las llamadas.
Los antipatrones reaparecen cuando los incentivos que los crearon permanecen.
Modelo mental completo de Software Architecture integra drivers, boundaries, datos, comunicación, operación, equipos y evolución en un proceso de decisión coherente.