Arquitectura de software
Ayudamos a equipos técnicos a tomar decisiones arquitectónicas que aguantan diez años. Monolito modular cuando es la respuesta correcta, microservicios cuando se justifican, event-driven cuando el dominio lo pide, DDD cuando el dominio es rico de verdad — y la combinación que aplique cuando el sistema ya está en producción y no se puede parar.
- Más de una década definiendo arquitecturas para multinacionales y administraciones
- Domain-Driven Design aplicado, no recitado: bounded contexts y lenguaje ubicuo
- Auditoría de arquitectura con plan priorizado y ADRs trazables
- Rescate de sistemas heredados sin rewrite total: strangler fig, anti-corruption layers
Buena arquitectura es la que aguanta diez años, no la que se ve bien hoy
La industria reescribe sus modas cada cinco años: SOA, microservicios, serverless puro, monolito modular, mesh, event-driven, microfrontends. Cada moda lleva razón en un contexto y se aplica fuera de él produciendo años de complejidad innecesaria. La arquitectura buena no es la que recita el último libro; es la que permite que el sistema esté en producción dentro de diez años, que el equipo pueda seguir entregando valor sin reescribirlo todo y que el coste operativo sea proporcional al valor de negocio.
Nuestro trabajo en arquitectura empieza por entender el contexto real: qué dominio es, qué tamaño tiene el equipo, qué nivel de cambio sufre el dominio, qué presupuesto operativo es razonable, qué dependencias heredadas hay. Solo después elegimos el estilo. La elección por defecto sigue siendo el monolito modular bien estructurado; otras opciones requieren justificación explícita.
DDD aplicado donde el dominio realmente es rico
Domain-Driven Design es una de las herramientas más útiles que conocemos para dominios complejos — banca, sanidad, logística, sector público — y una de las más mal aplicadas en dominios CRUD. Si lo que estás construyendo es un formulario con cinco entidades, DDD es overhead. Si es un sistema de gestión hospitalaria con flujos clínicos, reembolsos y regulaciones, no aplicarlo es la fuente garantizada del próximo rewrite.
Cuando aplica, trabajamos los conceptos en serio: event storming con los expertos de dominio del cliente para descubrir bounded contexts, lenguaje ubicuo escrito y respetado, agregados con invariantes claras, separación entre command y query cuando aporta, y mapeo explícito de las relaciones entre contextos (customer-supplier, conformist, anti-corruption layer). Lo entregable concreto son diagramas C4, ADRs, y una codebase organizada por bounded context.
Monolito modular, microservicios, event-driven y combinaciones
Monolito modular bien estructurado: la opción por defecto para la mayoría de productos. Módulos con fronteras claras, dependencias dirigidas, una sola base de datos, despliegue único. Te lleva muy lejos sin la complejidad operativa de los microservicios. Cuando hace falta extraer servicios, los módulos ya están preparados para ello.
Microservicios: cuando hay equipos independientes con dominios diferenciados, requisitos de escalado muy distintos por componente o necesidad real de despliegue independiente. Implican dedicar parte del equipo a la plataforma (observabilidad, mensajería, descubrimiento de servicios, contratos entre servicios) y por eso no son gratis. Event-driven: cuando el dominio es asíncrono por naturaleza (logística, fintech, marketplaces) o cuando se necesita desacoplar productores y consumidores con replay y auditoría natural. Apuesta consciente: aceptar la complejidad de eventual consistency a cambio de una arquitectura más resistente.
Sistemas heredados sin rewrite total
La mitad de los proyectos de arquitectura que recibimos no son nuevos: son sistemas que llevan años en producción, han acumulado deuda y necesitan evolucionar sin parar. Aquí no hay tiempo para un rewrite de dos años — y, sinceramente, casi nadie sobrevive a uno. La técnica que aplicamos por defecto es strangler fig (patrón de Martin Fowler): identificar los puntos de extensión, construir un anti-corruption layer entre lo nuevo y lo viejo, sustituir progresivamente funcionalidades, y retirar el sistema antiguo solo cuando todas las funcionalidades vivas hayan migrado.
Esto se combina con auditoría de arquitectura entregable: foto realista del sistema actual, mapa de bounded contexts implícitos, registro de hallazgos priorizados por impacto/esfuerzo y plan de evolución a 6, 12 y 24 meses con ADRs que documentan cada decisión. El cliente queda con material auditable y reutilizable, no con un PowerPoint que se evapora cuando termina el contrato.
Tecnologías y herramientas que usamos
No es un catálogo de logos: es la combinación concreta con la que entregamos producto. Elegimos por problema, no por moda.
Modelado y documentación
- > Event storming
- > Diagramas C4
- > ADRs (Markdown)
- > Domain Storytelling
- > Wardley maps cuando aplica
Estilos arquitectónicos
- > Monolito modular
- > Microservicios
- > Event-driven
- > CQRS / Event Sourcing
- > Arquitectura hexagonal
Mensajería e integración
- > NATS
- > Kafka
- > RabbitMQ
- > AWS EventBridge / SNS / SQS
- > Webhooks con outbox pattern
Datos y persistencia
- > PostgreSQL como default
- > DynamoDB para alta escala
- > ClickHouse para analítica
- > Outbox / Inbox patterns
- > Sagas distribuidas
Evolución de heredados
- > Strangler fig
- > Anti-corruption layer
- > Change Data Capture
- > Read models proyectados
- > Feature flags
Preguntas frecuentes sobre arquitectura de software
Las dudas más concretas que nos plantean los CTOs y direcciones técnicas. Si la tuya no está, escríbenos directamente.
¿Aplicáis microservicios por defecto?+
¿Hacéis Domain-Driven Design en todos los proyectos?+
¿Cómo entregáis una auditoría de arquitectura?+
¿Podemos rescatar nuestro sistema heredado sin pararlo?+
¿Quién lidera vuestros engagements de arquitectura?+
¿Buscas una respuesta más general? Revisa también el FAQ completo o nuestra página de clientes.
Cuéntanos la decisión arquitectónica que tienes encima de la mesa
Diseño nuevo, auditoría de arquitectura existente, rescate de un sistema heredado o segunda opinión sobre una decisión técnica importante. Te respondemos en menos de 24 horas laborables.
Respuesta estimada < 24h