Buscamos un(a) Arquitecto(a) de Soluciones capaz de sentarse con el negocio, entender el problema real, modelar el dominio y salir de esa conversación con una arquitectura defendible: capacidades y límites del dominio claramente identificados, alternativas evaluadas, decisiones escritas con sus consecuencias, diagramas que se entiendan sin necesidad de que alguien los explique y requisitos no funcionales medibles.

El diferenciador de este rol no es la profundidad en una sola tecnología. Es la capacidad de moverse entre el comité de negocio y la sala de construcción, traduciendo en ambas direcciones y acompañando al equipo hasta que la solución está en producción.

Esperamos que utilice Domain-Driven Design (DDD) cuando la complejidad del problema lo justifique, no como una colección de patrones obligatorios, sino como una herramienta para entender el dominio, construir un lenguaje común con el negocio, identificar bounded contexts, definir responsabilidades y evitar arquitecturas condicionadas exclusivamente por sistemas o tecnologías existentes.

Responsabilidades principales

1. Entender y modelar el dominio junto con las áreas de negocio y tecnología: levantar contexto, objetivos, actores, procesos, reglas, capacidades, sistemas involucrados, restricciones y supuestos, utilizando un lenguaje ubicuo (Ubiquitous Language) que permita construir un entendimiento compartido del problema.

2. Identificar dominios, subdominios y Bounded Contexts cuando la complejidad del negocio lo requiera, definiendo claramente sus responsabilidades, límites, relaciones e integraciones antes de trasladarlos a componentes tecnológicos.

3. Convertir las necesidades del negocio en problemas arquitectónicos bien planteados, con criterios de aceptación verificables, evitando saltar prematuramente del requerimiento a una tecnología o producto específico.

4. Proponer y comparar alternativas de solución contra atributos de calidad, complejidad, evolución y coste, sustentando la recomendación con los trade-offs explícitos: qué se gana, qué se sacrifica y qué consecuencias introduce cada decisión.

5. Diseñar y documentar la arquitectura con el modelo C4, utilizando contexto y contenedores como base, componentes donde aporten valor, y vistas dinámicas y de despliegue cuando el caso lo exija. Los límites arquitectónicos deben ser coherentes con los Bounded Contexts y responsabilidades del dominio definidos durante el diseño.

6. Definir requisitos no funcionales cuantificados, incluyendo disponibilidad, latencia, TPS, concurrencia, RTO/RPO, seguridad y mantenibilidad, utilizando escenarios de calidad y métricas verificables, no adjetivos.

7. Registrar las decisiones arquitectónicas significativas mediante Architecture Decision Records (ADR), documentando contexto, alternativas consideradas, decisión tomada y consecuencias positivas y negativas.

8. Diseñar la interacción entre Bounded Contexts, sistemas y servicios, definiendo explícitamente contratos, ownership de datos, dependencias y mecanismos de integración, evitando acoplamientos innecesarios entre dominios.

9. Cuando el diseño lo requiera, aplicar patrones tácticos de DDD como Entities, Value Objects, Aggregates, Domain Services y Domain Events, manteniendo las reglas e invariantes de negocio dentro del modelo de dominio y evitando modelos puramente anémicos.

10. Ejercer gobierno sobre la construcción: revisar la adherencia de la implementación a las decisiones arquitectónicas y al modelo de dominio, identificar brechas y acordar planes de acción con los equipos.

11. Acompañar al equipo durante la implementación: resolver dudas de diseño, validar impactos y ajustar la arquitectura y el modelo de dominio cuando aparezca nueva información, en lugar de entregar un documento y desaparecer.

Requisitos

1. 5+ años en arquitectura de soluciones, o en ingeniería con responsabilidad demostrable de diseño end-to-end.

2. Capacidad probada para traducir problemas de negocio en modelos de dominio y decisiones arquitectónicas. En la entrevista te pediremos narrar una arquitectura propia de punta a punta, incluyendo cómo entendiste el dominio, qué alternativas consideraste, cuáles descartaste y por qué.

3. Experiencia práctica aplicando Domain-Driven Design (DDD) en problemas de negocio con complejidad suficiente para justificarlo, especialmente:

   • Ubiquitous Language.
   • Dominios y subdominios.
   • Bounded Contexts.
   • Context Mapping.
   • Entities y Value Objects.
   • Aggregates y Aggregate Roots.
   • Domain Services.
   • Domain Events.

   Nos interesa más cómo utilizaste DDD para tomar mejores decisiones de diseño que la memorización de patrones o terminología.

4. Dominio real del modelo C4: notación correcta, tecnología explícita, relaciones etiquetadas con intención y protocolo, y coherencia entre niveles de abstracción.

5. Definición de requisitos no funcionales medibles y escenarios de calidad.

6. Registro de decisiones de arquitectura mediante ADR como práctica habitual.

7. Diseño de integraciones y APIs con enfoque contract-first: versionamiento, estándares, gobierno y definición clara de contratos entre sistemas y contextos.

8. Experiencia con al menos un proveedor cloud y su marco de buenas prácticas; en AWS, conocimiento de los seis pilares del Well-Architected Framework.

9. Seguridad por diseño: autenticación y autorización, manejo de datos sensibles y capacidad de identificar amenazas sobre su propio diseño.

10. AWS Certified Solutions Architect – Associate vigente (excluyente). Se valida con el enlace del badge de Credly.

Deseables

1. AWS Certified Solutions Architect – Professional vigente.

2. Experiencia avanzada en DDD, incluyendo diseño de Context Maps, patrones de relación entre Bounded Contexts, evolución de límites de dominio y estrategias para modernización de sistemas legacy utilizando límites de dominio.

3. Conocimiento de Event Storming u otras técnicas colaborativas de descubrimiento y modelado de dominio.

4. Arquitectura orientada a eventos: capacidad de distinguir entre Event Notification, Event-Carried State Transfer, Event Sourcing y CQRS, entendiendo especialmente cuándo no utilizarlos.

5. Experiencia combinando DDD con arquitectura hexagonal, Clean Architecture u otros enfoques que permitan aislar el dominio de infraestructura y frameworks, sin aplicarlos de forma dogmática.

6. Documentación con arc42 y diagramas como código mediante Structurizr, LikeC4, PlantUML o Mermaid, versionados junto al repositorio.

7. TOGAF, ATAM o experiencia en modernización incremental de sistemas core.

8. Experiencia en sectores regulados: resiliencia operacional, auditabilidad y gestión de riesgo de terceros.

9. Diseño de soluciones con componentes de IA y agentes, con criterio sobre cuándo aportan valor y cuándo no.