Arquitectura de microservicios

Del diseño conceptual al código: SOLID en la nube, bounded contexts, agregados con Java 21, 12-factor y el patrón transactional outbox.

Sumario

Qué vas a ver

Cómo pasar del diseño conceptual al código de un sistema de microservicios: límites del dominio, modelo táctico y las reglas para que ese diseño sobreviva en la nube.

SOLID elevado a la nube

• S. Un servicio es un bounded context. El anti-patrón es el monolito distribuido: varios despliegues que siguen acoplados.
• O. Se extiende con eventos de dominio. Un consumidor nuevo no toca el servicio de origen.
• L. El contrato v2 sustituye a v1 sin romper clientes. Si no, hay ruptura de contrato.
• I. Se evita la God API. Cada canal (web, mobile, IoT) habla con un BFF, y el BFF habla con los servicios de dominio.
• D. Arquitectura hexagonal. El dominio define los puertos y la infraestructura se adapta: API REST, cola de mensajes o base de datos.

DDD estratégico

"Producto" no es un solo servicio. En el ejemplo se parte en tres contextos:

• Catálogo: descripciones y SEO.
• Inventario: SKU y stock. Se protege con una anticorruption layer.
• Pricing: promociones.

Catálogo e Inventario se relacionan como customer/supplier. Inventario y Pricing comparten un published language por Kafka.

Un microservicio bien dimensionado es exactamente un bounded context. Dividir mal sale caro.

DDD táctico

El agregado de ejemplo es un pedido:

• Aggregate root: Order. Guarda las invariantes.
• Entity: OrderLine. Tiene identidad local.
• Value objects: Money y Sku. Son inmutables. En Java 21 un record ya trae equals y hashCode.

Regla de oro: una transacción de base de datos modifica un solo agregado.

public record Sku(String value) {}

public record Money(BigDecimal amount, String currency) {}

12-factor: el ADN cloud-native

El ciclo es build, release y run.

• Factor 3, config. Los secretos no viven en application.yml. Van en variables de entorno.
• Factores 6 y 8, stateless y concurrencia. El proceso no guarda estado. El estado vive en la base de datos.
• Factor 9, disponibilidad. Arranque en milisegundos con Quarkus y GraalVM, y apagado graceful.
• Factor 11, logs. El proceso escribe a stdout. Una plataforma centralizada (ELK, Splunk) los recoge.

Transactional outbox

Escribir el pedido en la base y publicar el evento en Kafka por separado es una escritura dual. Si el pedido queda grabado y el evento no sale, el inventario se desincroniza.

La salida es una sola transacción:

1. Insert del pedido.
2. Insert en la tabla outbox.

Un poller o Debezium (CDC) publica después a Kafka. La garantía es at-least-once, así que los consumidores tienen que ser idempotentes.