3.2 Estilos y patrones arquitectónicos

Visión general y motivación

Un estilo arquitectónico es una forma reutilizable y de amplio alcance para organizar un sistema: cómo se descompone, cómo se comunican sus partes y dónde se trazan las fronteras. Elegir uno de estos estilos es, con diferencia, una de las decisiones más determinantes (y más mal comprendidas) que una organización grande puede tomar. Con demasiada frecuencia, esa elección se deja llevar por la moda (“todos están migrando a microservicios”) en lugar de guiarse por las restricciones reales del equipo, del dominio y de la operación. El resultado suele ser uno de dos desastres: un sistema distribuido que la organización no es capaz de operar, o un monolito tan enredado que nadie se atreve a modificarlo con seguridad. Ninguno de los dos es culpa del estilo. Ambos provienen de un mismo error: casar el estilo con una situación que no le corresponde.

En equipos grandes de desarrollo, los estilos importan ante todo por la Ley de Conway: la estructura de un sistema tiende a reflejar la estructura comunicativa de la organización que lo construye. Un estilo arquitectónico es, por tanto, también una decisión de diseño organizativo. Segmentar un sistema en servicios es, en realidad, decidir cómo se dividen los equipos, cómo se reparte la responsabilidad de propiedad y cómo se cubre el on-call. Una empresa con cientos de ingenieros puede permitirse (y a menudo necesita) servicios finos con despliegue independiente, porque esa independencia es lo que permite a muchos equipos publicar sin bloquearse unos a otros. Imponer el mismo patrón a un equipo pequeño de un solo miembro hereda toda la carga operativa sin ningún beneficio organizativo a cambio.

En los entornos de gobierno y empresa se apilan restricciones adicionales: ciclos de vida largos, control de cambios estricto, procesos de adquisición, integración con sistemas de registro ya consolidados y exigencias de auditoría. Todo esto favorece estilos que mantienen fronteras explícitas y dependencias fáciles de inspeccionar. Este capítulo repasa los principales estilos: del monolito a los microservicios, las arquitecturas orientadas a eventos con CQRS y event sourcing, los patrones de service mesh y pasarelas, el paradigma serverless, y las disciplinas internas de la arquitectura hexagonal y la arquitectura limpia. Pero, sobre todo, busca ayudar a discernir cuándo conviene cada uno.

Véase también: capítulo 2.2 (principios de diseño de software, incluido el Diseño Orientado al Dominio), capítulo 3.1 (fundamentos de arquitectura) y capítulo 3.3 (sistemas distribuidos).

Principios clave

El estilo sigue a las fuerzas, no a la moda. Se elige en función del tamaño del equipo, la complejidad del dominio, la carga y la madurez operativa, nunca porque una tecnología esté de moda.
El acoplamiento es el verdadero enemigo, no el número de artefactos desplegables. Un monolito bien modularizado supera a un sistema distribuido que no es más que un enredo repartido.
Distribuir es un coste que se paga por la independencia. Solo se justifica la partición cuando el valor del despliegue, la escalabilidad o el aislamiento de fallos independientes supera al precio de las llamadas de red, los fallos parciales y la coherencia de datos entre servicios.
Las fronteras deben seguir al dominio del negocio. Los servicios y módulos deben alinearse con los contextos delimitados (cada uno, un modelo de dominio autónomo con su frontera explícita) , no con capas técnicas.
Diseñar bien el interior, sin importar el exterior. La arquitectura hexagonal o limpia mantiene la lógica de negocio independiente de los marcos y la infraestructura, en cualquier estilo.
La Ley de Conway es ineludible: hay que ponerla a trabajar. Diseñar juntos la arquitectura y los límites de los equipos.
Comenzar con algo más simple de lo que parece necesario. Se pueden extraer servicios de un buen monolito modularizado; deshacer un enredo de microservicios prematuros es mucho más difícil.

Recomendaciones

Por defecto, un monolito modularizado; segmentar con evidencia

La mayoría de los sistemas deberían nacer como una unidad desplegable única con fronteras internas firmes: interfaces claras, sin que un módulo acceda a los datos de otro y con reglas de dependencia que se aplican. Así se obtienen transacciones simples, refactorizaciones ágiles y una sola cosa que desplegar y monitorizar. Un módulo solo se convierte en servicio propio cuando existe un motivo concreto: un componente que debe escalar de forma independiente, un equipo que necesita su propio ritmo de despliegue, un dominio de fallo que hay que aislar o un requisito tecnológico que difiere del resto. Y cuando se segmenta, se hace por las líneas de contexto delimitado, de modo que cada servicio sea propietario de sus datos y exponga un contrato estable.

Saber cuándo los microservicios merecen su coste

Los microservicios ofrecen desplegabilidad independiente, escalado independiente, aislamiento de fallos y la libertad de combinar tecnologías. A cambio exigen un CI/CD (integración y entrega continuas) maduro, infraestructura automatizada, trazabilidad distribuida, descubrimiento de servicios y una cultura de guardia operativa. Hay que preguntarse con honestidad: ¿puede la organización operar decenas de servicios desplegados de forma independiente en producción con fiabilidad? Si la plataforma y la madurez operativa no están a la altura, los microservicios solo multiplican los modos de fallo sin entregar sus beneficios. Muchas organizaciones obtienen mejores resultados con un puñado de servicios de grano grueso alineados a grandes dominios, en lugar de una enjambre de servicios minúsculos.

Recurrir a la arquitectura orientada a eventos cuando el desacoplamiento y la asincronía compensan

La arquitectura orientada a eventos permite que los emisores publiquen hechos sin saber quién los consume. Eso otorga un acoplamiento flojo, un colchón ante picos de carga y una vía sencilla para añadir nuevos consumidores. Conviene allí donde los flujos de trabajo son naturalmente asíncronos y reactivos. CQRS (Command Query Responsibility Segregation) separa el modelo de escritura de uno o varios modelos de lectura, lo que resulta útil cuando las cargas o las formas de lectura y escritura difieren notablemente. El event sourcing almacena el estado como un registro de solo adición de eventos en lugar de como estado actual, proporcionando una trazabilidad perfecta y la capacidad de viajar en el tiempo. Es un recurso poderoso en finanzas y en el sector público, donde «¿cómo llegamos a este valor?» es una pregunta legal, pero añade complejidad real en la versión de eventos, la reconstrucción de proyecciones y el razonamiento sobre la coherencia eventual. Recurrir a estos patrones debe ser una decisión deliberada, no un hábito por defecto.

Aplicar patrones de pasarela, BFF y mesh para gestionar muchos servicios

Una pasarela de API ofrece a los clientes externos un único punto de entrada, gestionando autenticación, limitación de tasa, enrutamiento y terminación de TLS (Transport Layer Security). Un BFF (Backend for Frontend) proporciona a cada tipo de cliente (web, móvil, API de partners) su propia capa de agregación adaptada, evitando una API monolítica y de un solo tamaño para todos. Un service mesh desplaza las preocupaciones transversales (mutual TLS, reintentos, temporizaciones, desplazamiento de tráfico y telemetría) a una capa de infraestructura adyacente, de modo que los equipos de aplicación no tengan que reimplementarlas. Introducir un mesh solo cuando el número de servicios hace que gestionar esas preocupaciones servicio por servicio resulte inmanejable. Con pocos servicios, un mesh es más peso operativo que lo que aporta.

Ponderar el serverless con honestidad

Las plataformas de funciones como servicio y las plataformas serverless gestionadas alivian la gestión de servidores, escalan a cero y facturan por uso; son ideales para cargas picos, asíncronas o de baja actividad basal, y para equipos pequeños. Pero las contrapartidas son reales: latencia de arranque en frío, límites de tiempo de ejecución y de recursos, dificultad para probar en local, posible lock-in con un proveedor y un coste que en volumen sostenido y elevado puede superar al de infraestructura provisionada. El serverless se emplea donde su economía y su simplicidad operativa resultan claramente ventajosas. No se deben forzar sistemas nucleares de alto rendimiento y flujo constante hacia él por entusiasmo.

Mantener la lógica de negocio limpia en el interior de cada servicio

Sea cual sea el estilo exterior, el interior debe estar limpio mediante arquitectura hexagonal (puertos y adaptadores) o arquitectura limpia: las reglas de negocio en el centro, dependiendo solo de abstracciones; marcos, bases de datos y mensajería en los bordes, como adaptadores sustitutos. Así, la valiosa lógica de dominio se mantiene testeable sin infraestructura y portátil a través de los cambios tecnológicos: una ventaja decisiva para sistemas de empresa y sector público de larga vida, que sobrevivirán a varias generaciones de marcos.

Compromisos: ventajas y desventajas

Estilo	Cuándo conviene	Ventajas	Desventajas
Monolito modularizado	La mayoría de los sistemas, especialmente al inicio	Operación simple, transacciones y refactorización ágiles	Una sola unidad de despliegue; escala en bloque; riesgo de erosión
Microservicios	Muchos equipos, alta escala, plataforma madura	Despliegue y escalado independientes, aislamiento de fallos	Complejidad distribuida, coherencia de datos, alto coste operativo
Orientado a eventos / CQRS / event sourcing	Flujos asíncronos, necesidades de auditoría, lectura/escritura divergentes	Acoplamiento flojo, trazabilidad, lecturas escalables	Coherencia eventual, versión de eventos, depuración más difícil
Serverless	Cargas con picos o baja actividad basal, orientadas a eventos	Sin gestión de servidores, escalado a cero, pago por uso	Arranque en frío, límites, lock-in, coste elevado en carga sostenida

El tema recurrente: la flexibilidad y la independencia se pagan con complejidad operativa y cognitiva. Los estilos distribuidos y orientados a eventos renuncian a la simplicidad de una única pila de llamadas y una única transacción a cambio de la capacidad de escalar, desplegar y fallar con independencia. Ese intercambio merece la pena a gran escala y con una plataforma madura. Sin ambas condiciones, es ruinoso. Las disciplinas internas (hexagonal / limpia) casi siempre merecen la pena, pues cuestan poco y mantienen abiertas las opciones para cambiar de estilo en el futuro.

Preguntas para debatir con el equipo

Antes de segmentar el próximo servicio, se va a segmentar también al equipo que lo posee, y ¿quién tiene la autoridad para hacerlo? La Ley de Conway implica que una frontera de servicio es, en esencia, una frontera de equipo; una segmentación que el organigrama no respalda produce un monolito distribuido: dos artefactos desplegables, un solo tren de liberación, una guardia compartida. En una gran empresa, la autoridad para reorganizar equipos suele estar por encima de Ingeniería, entre líneas de reporte, finanzas y recursos humanos, por eso el diseño de arquitectura y el diseño organizativo deben tomarse a la par. Acudir al debate con evidencias: ¿el servicio propuesto tiene un equipo que pueda poseerlo de extremo a extremo, cubrir su propia guardia y desplegar a su propio ritmo? Si la respuesta es no, hay que financiar ese equipo o mantener la capacidad como un módulo dentro del monolito. Segmentar código sin segmentar la propiedad es pagar todo el coste de la distribución sin obtener ninguna de las ventajas de la independencia.
¿Se puede desplegar cada servicio de forma independiente hoy, o en realidad se publican todos en bloque? El monolito distribuido es el peor resultado posible en este capítulo: se pagan las llamadas de red, los fallos parciales y la coherencia de datos entre servicios, y aun así no se puede liberar uno sin los demás. Las señales de alarma son una base de datos compartida, una biblioteca compartida que impone actualizaciones coordinadas y pruebas de integración que exigen ejecutar todo el conjunto a la vez. En un equipo grande, esto limita silenciosamente el throughput, pues todos los equipos quedan en cola detrás de una misma liberación, aunque el diagrama muestre independencia. Tomar un cambio reciente y contar cuántos servicios tuvieron que desplegarse juntos para hacerlo seguro; si ese número es mayor de uno para un cambio que tocó una sola capacidad, las fronteras están mal trazadas. La solución suele ser dar a cada servicio sus propios datos y un contrato estable y versionado, no añadir más servicios.
¿Qué segmentos de servicios existentes han dejado de reportar beneficio y se debería volver a fusionarlos? El hábito más avanzado que propone este capítulo es tratar las decisiones de estilo como reversibles: extraer cuando aparece un motivador y volver a unificar cuando desaparece. La mayoría de las organizaciones solo fragmentan, de modo que los nanoservicios y los servicios centrados en una entidad se acumulan hasta que la orquestación y el sobrecoste de red superan el trabajo que cada servicio realiza. Buscar servicios que siempre se despliegan juntos, que existen por una tabla de base de datos en lugar de por una capacidad de negocio, o cuyos saltos de red ahora dominan la latencia de una petición. En patrimonios empresariales y de gobierno, donde las plantillas y los presupuestos están bajo escrutinio, plegar dos servicios delgados de vuelta en un solo servicio de grano grueso es una medida legítima y ahorradora, no una confesión de fracaso. Plantear la recon consolidación con la misma transparencia que la extracción, y decidir ambas con la misma evidencia.
¿La plataforma y la madurez en on-call de la organización sostienen realmente el estilo que se propone, y se pueden nombrar las carencias específicas antes de comprometerse? Los microservicios, los meshes y las espinas dorsales orientadas a eventos solo entregan sus beneficios sobre una base de CI/CD maduro, trazabilidad distribuida, descubrimiento de servicios y una cultura de guardia que sepa razonar ante el fallo parcial. En una gran organización, solemos decidir el estilo objetivo en un foro de arquitectura y descubrir después la plataforma que falta, cuando decenas de servicios ya están en producción y cada incidente tarda horas en diagnosticarse. Ponderar el atractivo del despliegue y el escalado independientes frente a la pregunta sobria de quién lo gestiona a las tres de la madrugada: la misma segmentación que libera a los equipos para que publiquen en paralelo también multiplica los modos de fallo que cada equipo debe comprender. Llevar un inventario honesto al debate: frecuencia de despliegue actual, tiempo medio de recuperación, si hay trazabilidad entre fronteras de servicio y cuántos servicios puede operar realista un solo equipo. En entornos empresariales y de gobierno, añadir los plazos de adquisición y contratación para las capacidades de plataforma que faltan, porque un estilo que presupone un mesh y un equipo de plataforma que no se ha financiado es un plan para gestionar un patrimonio insoportable.
¿En qué partes del dominio un registro de auditoría completo mediante event sourcing es una necesidad legal y no una comodidad, y quién tiene la autoridad para decidirlo? El event sourcing y el CQRS otorgan un historial perfecto y reconstruible y modelos de lectura que escalan por su cuenta, pero a cambio exigen versión de eventos, reconstrucción de proyecciones y razonamiento sobre coherencia eventual durante toda la vida del sistema. Aplicado a un dominio que nunca necesitó esa trazabilidad, la complejidad es un impuesto puro; retirado de un dominio donde «¿cómo llegamos a este valor?» es una obligación legal, su ausencia es un fallo de cumplimiento. Las consideraciones en tensión son la auditabilidad y la escalabilidad de consultas, de un lado, y la dificultad de depuración y la carga cognitiva del desarrollador, del otro; por tanto, la decisión corresponde a personas que entienden tanto la obligación regulatoria como la carga operativa, no a quien más entusiasta esté con el patrón. Presentar los requisitos concretos de retención y reconstrucción de carácter legal o contractual, el volumen de eventos esperado y una estimación honesta del trabajo de versión y proyección. En finanzas, fiscalidad y sector público, donde reconstruir una decisión años después puede ser un deber estatutario, designar al responsable que firma que un determinado contexto delimitado sí, o no, requiere un registro de eventos inmutable.
¿Cómo se va a impedir que el monolito modularizado se erode de modo que la extracción futura siga siendo barata, y qué mecanismo forzará las fronteras? Todo el caso a favor de empezar con un monolito modularizado descansa en la promesa de que fronteras internas limpias hacen que la extracción posterior de servicios sea asequible; pero esas fronteras se desmoronan en silencio en el momento en que un plazo empuja a un módulo a acceder a los datos de otro. En un equipo grande con muchos contribuidores, las buenas intenciones y las revisiones de código por sí solas no sostendrán la línea; sin un mecanismo de ejecución, el monolito se convertirá sin ruido en el enredo que el estilo pretendía evitar. Ponderar la fricción de las reglas de dependencia forzadas y las interfaces de módulo frente al coste de descubrir, años después, que ninguna frontera es real y que cada extracción significa desenredar un estado compartido. Aportar evidencia: ¿las fronteras de módulo están forzadas por herramientas de compilación, análisis estático o estructura de paquetes, o son convenciones documentadas que los últimos seis fusiones ignoraron? En sistemas empresariales y de gobierno de larga vida, que deben sobrevivir a un control de cambios estricto y a varias generaciones de marcos, tratar la ejecución de fronteras como un control auditable, de modo que la opción de distribuir en el futuro sea una que se ha preservado de verdad y no una que se supone que aún se posee.

Perspectiva por sector

Startups. El valor por defecto es un monolito modularizado único, resistiendo la tentación de los microservicios, porque el recurso más escaso es la atención del equipo de ingeniería y una enjambre de servicios es un impuesto operativo que no se puede permitir antes de alcanzar el product-market fit. Mantener fronteras limpias de módulo para poder extraer después, y recurrir al serverless donde el escalado a cero y el pago por uso se ajusten a una carga con picos y baja actividad basal. Extraer una sola cosa, y solo cuando aparece un motivador concreto, como un emisor de notificaciones con carga de ráfagas, y no antes.

Pequeña empresa. Sin equipo de plataforma y con un presupuesto ajustado, conviene un monolito o un puñado de servicios de grano grueso sobre una plataforma gestionada, y adquirir infraestructura alojada en lugar de construir meshes, trazabilidad y descubrimiento de servicios propios. Ponderar el serverless y las bases de datos gestionadas como una forma de no tener que operar servidores, y desconfiar de un diseño distribuido cuya carga operativa no hay nadie que la asuma. La arquitectura correcta es aquella que una o dos personas pueden realmente desplegar, monitorizar y recuperar.

Gran empresa. El verdadero problema es la multiplicidad de equipos y la Ley de Conway: alinear servicios de grano grueso a contextos delimitados y a la propiedad de equipo, e invertir deliberadamente en la plataforma (CI/CD, trazabilidad, mesh, descubrimiento de servicios) que hace segura la distribución. Estandarizar los patrones de pasarela, BFF y arquitectura limpia interna para que los grupos dejen de reinventarlos, y gobernar la extracción y la re-consolidación como decisiones de cartera basadas en evidencia, no como preferencias locales. Presupuestar el coste operativo de cada segmentación de forma explícita, porque a esta escala el fracaso del monolito distribuido es caro y lento de deshacer.

Sector público. Los ciclos de vida largos, el control de cambios estricto, los procesos de adquisición y las exigencias de auditabilidad condicionan la elección: favorecer estilos con fronteras explícitas e inspeccionables y contratos duraderos que sobrevivan a proveedores y a generaciones de marcos. El event sourcing justifica su complejidad donde reconstruir una decisión dirigida a la ciudadanía es un deber estatutario; usarlo de forma deliberada para los registros principales y mantener la arquitectura limpia en el interior de cada servicio para aislar las reglas que cambian con cada presupuesto. Tratar la portabilidad y la salida de plataformas serverless o de proveedores propietarios como requisitos de adquisición, no como consideraciones a posteriori.

Ejemplos

Startups. Una startup de cuatro personas que construye un producto de programación siente presión para empezar con microservicios porque un blog de un competidor los ha promocionado, pero resiste. Lanza un monolito modularizado único con fronteras internas claras (programación, facturación, notificaciones) como módulos separados en un solo artefacto desplegable, de modo que un solo ingeniero puede ejecutar todo el sistema en local y una liberación es un solo push. Cuando el producto gana tracción, solo el emisor de notificaciones, que se ramifica a correo y SMS bajo carga de ráfagas, se extrae como servicio propio. No hereda la carga operativa de una docena de servicios mientras aún busca el product-market fit.

Gran empresa. Una gran empresa de comercio electrónico empieza como monolito modularizado. A medida que el tráfico crece y se multiplican los equipos, extrae los dominios de mayor carga y evolución más independiente (catálogo, carrito, pago y búsqueda) como servicios separados, cada uno propietario de sus datos. El servicio de pago emite eventos que inventario, cumplimiento y analítica consumen a través de una espina dorsal de eventos, de modo que nuevos consumidores (detección de fraude, fidelización) pueden conectarse sin tocar el pago. Una pasarela de API gestiona la autenticación y la limitación de tasa, y un BFF adapta los payloads para móvil. Los dominios de menor tráfico siguen en el monolito, lo que evita una fragmentación innecesaria.

Sector público. Una administración tributaria construye una plataforma de liquidación sobre event sourcing para el registro principal, porque cada cambio en la obligación de un contribuyente debe ser reconstruible y auditable legalmente durante años. Los comandos (presentar declaración, aplicar pago, emitir ajuste) producen eventos inmutables, y los modelos de lectura proyectan saldos actuales para funcionarios y ciudadanos. El CQRS permite que el lado de consultas, orientado al público, escale por su cuenta durante la temporada alta de declaraciones sin poner en riesgo el lado de escritura. En el interior, cada servicio sigue la arquitectura limpia, de modo que las reglas de liquidación, que cambian con cada presupuesto, quedan aisladas de la tecnología de persistencia y mensajería.

Justificación de negocio: motivaciones, retorno y coste total de propiedad

El dinero en juego en la elección de un estilo es enorme, porque la decisión es costosa de revertir. Adoptar microservicios demasiado pronto infla el coste total de propiedad a través de la construcción de plataforma, la infraestructura duplicada, la depuración distribuida y una mayor carga operativa: costes que se arrastran durante toda la vida del sistema. Rechazar segmentar un monolito genuinamente sobrecargado limita el throughput de entrega: los equipos hacen cola detrás de una liberación compartida y cada cambio pone en riesgo el sistema entero. La conversación sobre el retorno de la inversión es, en el fondo, acerca de ajustar el gasto operativo a la necesidad organizativa.

Plantear el caso ante la dirección en términos de throughput y riesgo, no de tecnología. La desplegabilidad independiente significa más equipos publicando en paralelo y tiempos de entrega más cortos: velocidad de negocio medible. El aislamiento de fallos significa menos incidencias totales y un área de impacto menor: disponibilidad y protección reputacional medibles. Pero ser igual de honesto sobre la inversión de plataforma que cada estilo exige: un mesh, la trazabilidad y la madurez del CI/CD son prerrequisitos, no extras opcionales, y su coste debe incluirse en el coste total de propiedad. Para muchas organizaciones, el camino más económico es un monolito bien modularizado ahora, con fronteras internas limpias que hacen que la extracción posterior sea barata. Eso compra la opción de distribuir sin pagarla antes de ser necesario.

Antipatrones y errores comunes

Monolito distribuido. Servicios que deben desplegarse juntos y comparten una base de datos: todo el coste de la distribución, ninguna de las ventajas de la independencia.
Nanoservicios. Servicios tan finos que la orquestación y el sobrecoste de red superan el trabajo que realizan.
Microservicios sin plataforma. Segmentar antes de contar con CI/CD, trazabilidad y madurez en on-call; los modos de fallo se multiplican.
Servicios de entidad. Segmentar por tabla de base de datos («servicio de usuario», «servicio de pedido») en lugar de por capacidad de negocio, forzando llamadas cruzadas entre servicios en cada operación.
Event sourcing por todos lados. Aplicarlo a dominios que no necesitan trazabilidad de auditoría y pagar la complejidad sin ningún beneficio.
Pasarela como monolito. Introducir lógica de negocio en la pasarela de API, recreando un punto de estrangulamiento central.
Núcleo acoplado al marco. Lógica de negocio enredada con el marco web o con el ORM (mapeo objeto-relacional), haciendo dolorosas tanto las pruebas como el cambio tecnológico.

Modelo de madurez

Nivel 1: Iniciar. El estilo se elige por moda o por accidente. Existe un monolito enredado o un enredo distribuido accidental, las fronteras siguen capas técnicas o historia en lugar del dominio, y las segmentaciones ocurren de forma reactiva cuando algo se rompe.
Nivel 2: Desarrollar. Algunos equipos trazan fronteras de módulo deliberadas dentro del monolito o ponen en pie unos pocos servicios de grano grueso, y algunas preocupaciones transversales se gestionan de forma consistente. La práctica es desigual: un grupo alinea servicios a contextos delimitados mientras otro aún segmenta por tabla de base de datos, y la extracción sigue siendo ad hoc.
Nivel 3: Estandarizar. Existe un enfoque documentado que se aplica en toda la organización: los servicios se alinean a contextos delimitados y son propietarios de sus datos, se usan los patrones de pasarela y BFF donde corresponde, la arquitectura limpia o hexagonal interna es el estándar, y cada segmentación requiere un motivador declarado. Las fronteras de módulo se ejecutan por herramienta, no solo por convención.
Nivel 4: Gestionar. Las decisiones de estilo se miden y controlan frente a líneas base. Se rastrea la frecuencia de despliegue y el tiempo de entrega por servicio, el tiempo medio de recuperación, cuántos servicios deben desplegarse juntos para un cambio típico y la latencia por salto de red, y se compara el coste de cada segmentación con la independencia que debía comprar. La evidencia, no la preferencia, decide si una frontera sobrevive, y la deriva hacia un monolito distribuido se detecta por métricas y no por una incidencia.
Nivel 5: Orquestar. La arquitectura se integra con el diseño organizativo y se adapta de forma continua. Una plataforma madura (CI/CD, trazabilidad y mesh donde corresponda) hace baratas tanto la distribución como la re-consolidación, los equipos extraen de forma rutinaria cuando aparece un motivador y pliegan servicios de vuelta cuando desaparece, y las decisiones de estilo se reequilibran a medida que la topología de equipos, la carga y el panorama de riesgo evolucionan en todo el patrimonio.

Ideas para el debate

¿En qué partes del sistema el monolito es en realidad una fortaleza y en cuáles es un cuello de botella genuino?
¿Qué motivador concreto justificaría extraer el próximo servicio, y puede nombrarse antes de construirlo?
¿Cuenta la organización con la madurez operativa que los microservicios exigen? ¿Qué falta?
¿En qué partes del dominio un registro de auditoría completo mediante event sourcing es una necesidad legal o de negocio frente a un capricho?
¿Hasta qué punto las fronteras actuales de servicio reflejan las fronteras del equipo, y esa alineación ayuda o perjudica?
Si el año que viene hubiera que cambiar el marco web o la base de datos, ¿qué parte de la lógica de negocio habría que reescribir?

Puntos esenciales

Elegir el estilo arquitectónico a partir de fuerzas reales (tamaño del equipo, dominio, carga, madurez operativa), no de la moda.
Un monolito modularizado es el valor por defecto para la mayoría de los sistemas; extraer servicios solo con un motivador concreto y por las líneas de contexto delimitado.
Los microservicios cambian la complejidad operativa y cognitiva por despliegue, escalado y aislamiento de fallos independientes; exigen una plataforma madura.
La orientación a eventos, el CQRS y el event sourcing ofrecen desacoplamiento y auditabilidad a cambio de coherencia eventual y complejidad de versión; adoptar con deliberación.
Las pasarelas, los BFF y los meshes doman patrimonios de muchos servicios pero añaden peso; introducirlos cuando la escala lo exija, no antes.
Aplicar la arquitectura hexagonal o limpia en el interior de cada servicio para mantener la valiosa lógica de negocio testeable y durable a través de los cambios tecnológicos.

Referencias y lecturas recomendadas

Sam Newman, Building Microservices y Monolith to Microservices
Chris Richardson, Microservices Patterns
Eric Evans, Domain-Driven Design
Vaughn Vernon, Implementing Domain-Driven Design
Robert C. Martin, Clean Architecture
Alistair Cockburn, «Hexagonal Architecture (Ports and Adapters)»
Gregor Hohpe y Bobby Woolf, Enterprise Integration Patterns
Martin Fowler, Patterns of Enterprise Application Architecture (y artículos sobre CQRS y Event Sourcing)
Matthew Skelton y Manuel Pais, Team Topologies