El plan de descomposición de la lección anterior deja seis servicios con fronteras dibujadas a trazo grueso. Falta lo que separa un diseño aceptable de uno bueno: decidir con precisión dónde termina el significado de cada palabra. En el monolito de TechCorp, "producto" es una fila de la tabla productos y todo el mundo la usa; pero lo que el catálogo entiende por producto (una ficha con descripción, imágenes y atributos) no es lo que entiende inventario (un identificador con cantidades) ni lo que entiende pedidos (un nombre y un precio congelados en el momento de la compra). Mientras las tres áreas compartían tabla, la ambigüedad se toleraba. En cuanto son servicios, la ambigüedad se convierte en acoplamiento.

Domain-Driven Design (DDD) llama a esto DDD estratégico y ofrece las herramientas para hacerlo bien: subdominios, lenguaje ubicuo, bounded contexts, mapa de contextos y agregados. Esta lección las aplica una a una a TechCorp: clasificaremos los subdominios, veremos ejemplos concretos de ambigüedad, definiremos los seis contextos y su relación con los servicios, dibujaremos el mapa de contextos con sus patrones de relación, definiremos el agregado Pedido (y por qué el stock no forma parte de él) y concretaremos qué campos de "producto" y de "cliente" guarda cada contexto. Cómo se materializa eso en bases de datos físicas separadas es el tema de 02-04.

1. DDD estratégico en pocas palabras
2. Los subdominios de TechCorp: core, soporte y genéricos
3. Lenguaje ubicuo: cuando "producto" y "cliente" no significan lo mismo
4. Qué es un bounded context y cómo se relaciona con un microservicio
5. El mapa de contextos y sus patrones de relación
6. Agregados y raíces de agregado: la frontera transaccional
7. El modelo de datos de cada contexto

DDD (Eric Evans, 2003) tiene dos mitades. La táctica habla de cómo escribir el código de un modelo (entidades, objetos de valor, repositorios, servicios de dominio). La estratégica habla de cómo dividir un problema grande en modelos que puedan evolucionar por separado. Para diseñar microservicios, la mitad estratégica es la que importa, y se apoya en cinco ideas:

La distinción que más confusión genera: subdominio es un trozo del problema (existe aunque no haya software); bounded context es un trozo de la solución (un modelo que construimos). Lo ideal es que coincidan uno a uno, y en TechCorp así será, pero conviene tener claro que son cosas distintas.

DDD clasifica los subdominios según su valor competitivo, y esa clasificación dicta cuánto esfuerzo de diseño merece cada uno:

• Core (núcleo): donde la empresa se diferencia. Es lo que hay que diseñar con más cuidado y con el mejor equipo, y lo que nunca se compra hecho.
• De soporte: necesario para el negocio, específico de la empresa, pero no diferenciador. Se diseña bien, sin obsesión.
• Genérico: un problema resuelto igual en todas las empresas. Se compra, se usa un servicio externo o se implementa de la forma más sencilla posible.

Esta tabla justifica decisiones que ya tomamos por intuición: por qué el catálogo y los pedidos concentran la inversión, por qué la identidad no aparece en el mapa de servicios y por qué Notificaciones debe ser aburrido.

El lenguaje ubicuo es el vocabulario que negocio y desarrollo usan sin traducción, y que aparece tal cual en el código (por eso los identificadores del curso están en español: crearPedido, PedidoRepositorio, clienteId). La observación clave de DDD es que el lenguaje ubicuo solo es coherente dentro de un contexto: la misma palabra cambia de significado al cruzar la frontera, y pretender un único modelo "producto" para toda la empresa produce un modelo gigante que no sirve bien a nadie (es la tabla productos + atributos_producto de TechCorp).

La consecuencia práctica más importante está en la tercera fila: si el catálogo cambia el precio de p-501 mañana, el pedido ped-88213 de hoy no debe cambiar. Por eso pedidos guarda una copia congelada de nombre y precio en lineas_pedido, y por eso el evento "Precio cambiado" del event storming de 02-02 no le interesa. No es duplicación accidental: es que son dos conceptos distintos que comparten identificador.

• "Estado": en Pedidos, PENDIENTE / CONFIRMADO / CANCELADO; en Pagos, AUTORIZADO / CAPTURADO / REEMBOLSADO; en Inventario, una reserva está ACTIVA / CONSUMIDA / LIBERADA. Tres máquinas de estados distintas que hoy conviven en columnas estado TEXT sin relación.
• "Cancelar": para Pedidos es cerrar el pedido sin completarlo; para Pagos es no capturar un cobro autorizado; para Inventario es liberar una reserva. La saga de 02-05 encadenará las tres, pero cada contexto usa su verbo.
• "Disponible": en Catálogo significa publicado; en Inventario significa cantidad - reservado > 0. Un producto puede estar disponible en catálogo y no en inventario, y viceversa.

Detectar estas colisiones es, en la práctica, la forma más fiable de encontrar fronteras: allí donde una palabra cambia de significado, hay una costura.

Un bounded context es el límite explícito dentro del cual un modelo de dominio y su lenguaje ubicuo son coherentes. Dentro, "producto" significa una sola cosa; fuera, puede significar otra. Cada contexto tiene su propio modelo, su propio código y (como veremos en 02-04) sus propios datos.

La relación con los microservicios:

La regla de TechCorp: un contexto, un servicio, un equipo dueño. Y la excepción admitida: durante la migración, el monolito residual contiene varios contextos, cada uno en su módulo, con las abstracciones de 02-02 marcando dónde están las fronteras.

Los contextos no viven aislados: Pedidos necesita precios de Catálogo, Notificaciones necesita saber que un pedido se ha confirmado. El mapa de contextos dibuja esas relaciones y, sobre todo, quién manda en cada una: en cualquier relación hay un contexto upstream (aguas arriba: su modelo influye) y uno downstream (aguas abajo: se adapta o se protege). DDD cataloga los patrones de relación:

Aplicado a TechCorp:

Lectura relación por relación (U = upstream, D = downstream):

• Catálogo → Pedidos: OHS + PL con ACL en Pedidos. Catálogo publica un contrato abierto (GET /productos?ids=..., formato JSON documentado) para todos los consumidores (Pedidos, la web, futuros servicios). Pedidos no incorpora el modelo "ficha de catálogo" a su dominio: una pequeña capa (traductorProducto) convierte { productoId, nombre, precio, descripcion, atributos... } en lo único que Pedidos entiende, una LineaPedido con nombre y precio congelados. Así, si Catálogo cambia sus atributos, Pedidos no se entera.
• Clientes → Pedidos: Customer-Supplier. Pedidos necesita saber que el cliente existe y obtener email y dirección de envío. Es una relación negociada: el equipo de Pedidos puede pedir a Clientes que exponga un GET /clientes/{id} con exactamente esos campos.
• Pedidos ↔ Inventario: Partnership. Ambos son del equipo de Luis y evolucionan juntos: Pedidos publica pedido.creado, Inventario responde con stock.reservado (o su negativa). Los contratos de esos eventos se diseñan en la misma mesa. Nótese que Partnership no significa base de datos compartida: significa planificación compartida.
• Pedidos → Pagos → Pedidos: Customer-Supplier por eventos, con PL. Pagos consume stock.reservado y publica pago.confirmado (o su rechazo). El lenguaje publicado son los esquemas de esos eventos.
• Pedidos → Notificaciones: Conformist. Notificaciones acepta los eventos de Pedidos tal cual, sin pedir cambios: es un subdominio genérico y su trabajo es reaccionar. Si pedido.confirmado trae email y nombre, los usa; no tiene modelo propio de cliente que proteger.
• Keycloak → Clientes: Conformist. Keycloak es externo y estándar (OpenID Connect); Clientes se adapta a sus tokens y guarda el identificador de Keycloak (sub) junto al clienteId.
• Pasarela → Pagos: ACL. La pasarela tiene su propia API, sus propios estados y sus propios errores. servicio-pagos la envuelve en un adaptador (servicios/pasarelaPago.js, heredado del monolito y ahora en exclusiva) que traduce a los conceptos de Pagos: AUTORIZADO, CAPTURADO, RECHAZADO, REEMBOLSADO. Cambiar de pasarela solo toca esa capa.
• Shared Kernel: ninguno, por decisión. La tentación sería compartir "identificadores", "dinero" o "el sobre de los eventos" como librería común de dominio. TechCorp lo evita: los identificadores son cadenas opacas y el formato del sobre de eventos es lenguaje publicado (documentado), no código compartido. Es la misma regla de 02-02 sobre utilidades compartidas.
• Separate Ways: Catálogo y Notificaciones, Inventario y Clientes. No se hablan. Si Notificaciones algún día necesitara el nombre de un producto para un correo, lo recibiría en el evento antes que integrarse con Catálogo.

Bajamos un nivel. Dentro de un contexto, el modelo se organiza en agregados: grupos de objetos que se tratan como una unidad para cambios de estado. Cada agregado tiene una raíz (la única entidad a la que se accede desde fuera) y define una frontera de consistencia: los invariantes (reglas que siempre deben cumplirse) se garantizan dentro del agregado, en una única transacción; entre agregados, la consistencia es eventual.

Reglas prácticas de diseño de agregados:

1. Una transacción modifica un solo agregado. Si necesitas modificar dos, o el diseño está mal o toca aceptar consistencia eventual entre ellos (02-05).
2. Los agregados se referencian por identificador, nunca por objeto: un Pedido guarda clienteId, no un objeto Cliente.
3. Agregados pequeños. Un agregado grande bloquea mucho y escala mal.
4. La raíz protege los invariantes. Nadie modifica una línea de pedido "por fuera"; se pide al Pedido que la añada, y el Pedido comprueba que puede.

En el contexto Pedidos, el agregado es Pedido (raíz) con sus LíneaPedido (entidades internas) y su DirecciónEnvío (objeto de valor, copia). Sus invariantes:

• El total es siempre la suma de precioUnitario × cantidad de sus líneas.
• Un pedido tiene al menos una línea y ninguna línea tiene cantidad ≤ 0.
• Un pedido CONFIRMADO o CANCELADO no admite cambios de líneas.
• Las transiciones de estado siguen la máquina de estados que veremos en 02-05.

Qué no hay en este agregado, y por qué:

• No hay stock. El invariante "no reservar más de lo que hay" (cantidad - reservado >= 0) pertenece al contexto Inventario y a su agregado (una Reserva asociada a un pedidoId, o el propio Stock por producto). Meter el stock en el Pedido tendría tres problemas: (1) el Pedido debería conocer un invariante que no es suyo; (2) una fila de stock la tocan cientos de pedidos concurrentes, así que el agregado Pedido "abarcaría" filas compartidas por todos los pedidos y las transacciones se bloquearían entre sí (exactamente lo que pasaba en crearPedido con la pasarela dentro de la transacción); (3) el stock cambia por motivos ajenos al pedido (entradas de almacén, mermas). Por eso, en el diseño objetivo, Pedidos pide la reserva y la respuesta llega como evento.
• No hay objeto Cliente ni objeto Producto. Solo clienteId y productoId, más las copias de valor (dirección, nombre, precio) que el pedido necesita para ser autosuficiente.
• No hay pago. El Pago es agregado de otro contexto; el Pedido solo conoce que su estado pasó a PAGADO cuando llegó el evento.

Y en los otros contextos, los agregados principales:

Concretemos qué guarda cada contexto de los conceptos compartidos. Todavía no hablamos de bases de datos físicas (02-04), sino de qué campos existen en cada modelo.

Ejemplo del mismo producto visto desde cada contexto (formato ilustrativo; el esquema físico llega en 02-04):

Es la misma estructura que devolvía GET /pedidos/{id} en 01-01, ahora explicada: todo lo que hay dentro es del contexto Pedidos (referencias por id + copias de valor); nada de lo que hay dentro obliga a consultar otro contexto para leer el pedido.

• Buscar el "modelo canónico" de producto para toda la empresa. Es el camino de vuelta a la tabla productos + atributos_producto. Cada contexto tiene su producto; comparten identificador, no modelo.
• Confundir bounded context con módulo técnico. "Contexto de persistencia" o "contexto de API" no son bounded contexts: no tienen lenguaje de negocio propio.
• Agregados enormes. Un Pedido que contiene el Cliente, los Productos y el Stock "para tenerlo todo a mano" bloquea a media empresa en cada transacción. Referencias por id y copias de valor.
• Copiar datos "por si acaso" en lugar de por semántica. Pedidos copia nombre y precio porque el negocio dice que el pedido conserva el precio de la compra, no por rendimiento. Si copias algo que semánticamente debe estar siempre actualizado (por ejemplo, el email para contactar), tendrás datos obsoletos; ahí toca consultar o suscribirse a cambios (02-04).
• Ignorar el ACL con sistemas externos. Dejar que los estados de la pasarela de pago se filtren en el modelo de Pagos (y de ahí a los eventos) hace que cambiar de pasarela sea un cambio en toda la empresa.
• Consejo: mantén un glosario por contexto (una tabla: término, significado en este contexto, campo en el código). Cuando dos glosarios discrepen sobre una palabra, no lo resuelvas: es una frontera confirmada.

TechCorp estudia añadir dos capacidades: (a) valoraciones de productos por los clientes (estrellas y comentarios en la ficha) y (b) facturación (emisión de facturas legales por cada pedido confirmado). Para cada una: clasifícala como core, soporte o genérica; indica de qué contextos existentes sería downstream y qué patrón de relación usarías con cada uno.

En una reunión, el equipo de Inventario dice "el producto p-501 no está disponible" y el equipo de Catálogo responde "sí que lo está, lo publiqué ayer". Explica la ambigüedad con el vocabulario de esta lección, indica cómo la resolverías en los contratos (qué campo expone cada contexto) y qué debería mostrar la web al cliente en ese caso.

Para cada elemento, decide si forma parte del agregado Pedido, es un agregado propio del contexto Pedidos, o pertenece a otro contexto, y justifica con la regla de invariantes: (1) el cupón de descuento aplicado a un pedido; (2) el historial de cambios de estado del pedido; (3) la valoración que el cliente deja del pedido tras recibirlo; (4) la reserva de stock del pedido.

Ejercicio 1

(a) Valoraciones: subdominio de soporte (aporta a la experiencia, pero no es el núcleo de venta ni un problema genérico). Sería downstream de Catálogo (necesita saber que el producto existe: OHS + PL, consumiendo el contrato público) y de Pedidos o Clientes para verificar que quien valora compró el producto (Customer-Supplier: pediría un GET /pedidos?clienteId=...&productoId=... o un evento pedido.entregado). Su modelo de "producto" sería mínimo: productoId y nombre para mostrar. Podría vivir dentro del contexto Catálogo si es muy simple; como servicio propio si el volumen de escritura o el equipo lo justifican. (b) Facturación: subdominio de soporte con fuerte componente genérico (las reglas fiscales son iguales para todos; muchas empresas usan un proveedor). Downstream de Pedidos (Conformist o Customer-Supplier sobre pedido.confirmado, del que necesita líneas, importes e impuestos) y de Clientes (datos fiscales: Customer-Supplier, pidiendo un campo datosFiscales). Si se usa un proveedor externo de facturación, ACL delante de su API. Nunca compartiría tablas con Pedidos aunque "casi todo lo que necesita está en pedidos".

Ejercicio 2

"Disponible" tiene dos significados: en Catálogo, publicado (la ficha se muestra); en Inventario, con unidades libres (cantidad - reservado > 0). Ambos tienen razón en su contexto. En los contratos, cada uno expone su concepto con su nombre: Catálogo, publicado: true/false; Inventario, disponible: 113 (unidades libres) o hayStock: true/false. La web (o un BFF, 03-04) compone ambos: muestra la ficha porque está publicada y el botón "comprar" desactivado con el texto "sin stock" porque Inventario dice 0. Lo que no debe hacerse es añadir a la ficha del catálogo un campo stock mantenido a mano: es un dato de otro contexto (si se muestra, se obtiene por contrato o por réplica de eventos, 02-04).

Ejercicio 3

1. Cupón aplicado: dentro del agregado Pedido como dato de valor (descuentoAplicado, código y cantidad), porque afecta al invariante del total; la definición del cupón (validez, condiciones) es de otro contexto (Promociones), referenciado por código.
2. Historial de estados: puede ser parte del agregado (lista de transiciones con fecha) si es pequeño y se usa para validar transiciones; si crece o solo sirve para auditoría, agregado propio o simplemente un registro de eventos del contexto Pedidos. En ningún caso otro contexto.
3. Valoración del pedido: fuera del agregado y probablemente fuera del contexto: no afecta a ningún invariante del pedido y tiene ciclo de vida propio (llega días después, se puede editar). Referencia por pedidoId.
4. Reserva de stock: otro contexto (Inventario), agregado Reserva con pedidoId. Su invariante (cantidad - reservado >= 0) no es del Pedido, y meterla dentro haría que cada pedido bloquease filas compartidas por todos.

Con DDD estratégico hemos convertido las seis áreas de TechCorp en seis bounded contexts bien definidos: hemos clasificado sus subdominios (Pedidos y Catálogo como core; Inventario, Clientes y Pagos de soporte; Notificaciones e Identidad genéricos, esta última delegada en Keycloak), hemos comprobado que "producto", "cliente", "estado", "cancelar" y "disponible" significan cosas distintas en cada contexto y que esa diferencia marca las costuras, hemos dibujado el mapa de contextos con sus patrones (Catálogo como OHS + PL con ACL en Pedidos; Clientes → Pedidos como Customer-Supplier; Pedidos ↔ Inventario como Partnership; Pedidos → Notificaciones como Conformist; ACL frente a la pasarela; sin shared kernel por decisión) y hemos definido el agregado Pedido con sus líneas y su dirección congelada, dejando fuera el stock, el cliente y el pago por razones de invariantes y contención. Finalmente, hemos fijado qué campos guarda cada contexto de los conceptos compartidos: el catálogo tiene la ficha completa; inventario, productoId y cantidades; pedidos, copias congeladas de nombre y precio en sus líneas.

Todo esto sigue siendo modelo. La siguiente lección lo hace físico: una base de datos por servicio. Veremos por qué la base de datos compartida es el antipatrón principal, cómo se rompen las claves foráneas cruzadas del esquema de 01-05 (pedidos.cliente_id, lineas_pedido.producto_id), qué alternativas hay para las consultas que hoy son un JOIN, cómo se migran los datos sin parar la tienda y qué esquema concreto tendrá cada servicio, incluido el catálogo en MongoDB.