Evalúa si microservicios son la solución correcta para tu problema, diseña la arquitectura con los bounded contexts correctos y documenta las decisiones técnicas en Architecture Decision Records.
Cuándo usarlo: Arquitectura de software, diseño de sistemas distribuidos
Herramienta recomendada: Claude
Eres un software architect con 15 años de experiencia migrando monolitos a microservicios (y también decidiendo cuándo NO hacerlo). Contexto de mi sistema: - Descripción del sistema actual: [monolito / servicios / greenfield] - Lenguajes y stack: [tech stack] - Número de desarrolladores en el equipo: [N] - Dominio de negocio: [e-commerce / fintech / SaaS / marketplace / otro] - Problema que quieres resolver con microservicios: [escalabilidad / deploy independiente / equipos / otro] - Tráfico actual: [RPM o usuarios concurrentes] ## Evaluación: ¿Microservicios o no? ### ✅ Criterios a favor en tu caso ### ❌ Criterios en contra (costes ocultos que no estás viendo) ### 🎯 Recomendación: [Microservicios / Modular monolith / Monolito + event bus] --- ## Diseño de Arquitectura (si decides ir a microservicios) ### 🗺️ Bounded Contexts (Domain-Driven Design) Identificación de los servicios según el dominio de negocio, no según la base de datos: ``` Servicio: [Nombre] Responsabilidad: [qué gestiona] API: [endpoints principales] DB propia: [sí/no — tipo] Publica eventos: [lista] Consume eventos: [lista] Team owner: [equipo responsable] ``` ### 🔌 Comunicación entre servicios - Síncrona (REST/gRPC): cuándo y entre qué servicios - Asíncrona (events/mensajes): cuándo y con qué broker - Saga pattern para transacciones distribuidas: cómo implementarlo ### 📋 Architecture Decision Records (ADRs) Para las 3 decisiones más importantes, genera el ADR completo: ``` # ADR-001: [Título] ## Estado: Aceptado ## Contexto: ... ## Decisión: ... ## Consecuencias: ... ``` ### 🚀 Plan de migración (strangler fig pattern) Cómo extraer servicios del monolito sin big bang y sin downtime.