Con los principios de diseño como lista de comprobación, el equipo de Luis se enfrenta a la pregunta práctica: ¿por dónde se corta el monolito? Descomponer no es dibujar seis cajas con los nombres de las carpetas del repositorio. Es encontrar las costuras reales del sistema (los lugares donde el código y los datos ya están, o pueden estar, poco acoplados), decidir una estrategia de corte coherente, elegir un orden de extracción que minimice el riesgo y aplicar técnicas que permitan extraer piezas sin parar la tienda.

En esta lección recorremos las estrategias de descomposición (por capacidad de negocio, por subdominio, por casos de uso frente a recursos, por equipos), las técnicas para descubrir las costuras (event storming introductorio, análisis de dependencias del código y análisis de acoplamiento de las tablas del esquema SQL de 01-05), las dos técnicas de extracción segura más usadas (strangler fig y branch by abstraction), los criterios para ordenar la extracción y qué hacer con las utilidades compartidas como bd/conexion.js o servicios/correo.js. Terminamos con el ejemplo guiado: el monolito techcorp-shop descompuesto en los seis servicios del mapa objetivo, con el diagrama de dependencias antes y después. Cómo se reparten físicamente los datos (02-04) y cómo se sustituye la transacción única (02-05) quedan para las lecciones siguientes.

1. Qué significa descomponer (y qué no)
2. Estrategias de descomposición
3. Técnicas para descubrir las costuras
4. Extraer sin romper: strangler fig y branch by abstraction
5. En qué orden extraer: riesgo, valor y dependencias
6. Qué hacer con las utilidades compartidas
7. Ejemplo guiado: techcorp-shop en seis servicios

Descomponer un monolito es redistribuir responsabilidades, código y datos en unidades autónomas que cumplan los principios de 02-01. Tres aclaraciones evitan malentendidos frecuentes:

• No es "un servicio por carpeta". Que el monolito tenga controladores/pedidosControlador.js no garantiza que "pedidos" sea una buena frontera: como vimos, esa función toca cinco áreas. Las carpetas son una pista, no la respuesta.
• No es "un servicio por tabla". Sería el servicio de entidad de 01-04. Un servicio agrupa las tablas que cambian juntas bajo una capacidad.
• No es un acto único. Es un proceso incremental en el que cada extracción deja el sistema funcionando y aporta valor por sí misma. Si una extracción solo tiene sentido "cuando estén todas", es un big bang disfrazado.

El resultado de la descomposición es un plan: qué servicios habrá, qué se lleva cada uno del monolito, en qué orden se extraen y con qué técnica. Ese plan es el entregable de esta lección para TechCorp.

Hay cuatro formas habituales de decidir las fronteras. No son excluyentes: en la práctica se combinan, y una sirve para validar a otra.

Se pregunta "¿qué hace la empresa?" y se responde con una lista de capacidades estables en el tiempo: gestionar el catálogo, controlar el inventario, tramitar pedidos, cobrar, atender clientes, comunicarse con ellos. Cada capacidad tiene un responsable de negocio, un vocabulario y un ritmo de cambio propios (principio 3 de 02-01).

Es la estrategia más usada porque las capacidades cambian mucho menos que la tecnología o la organización: TechCorp cobraba pedidos hace diez años y los cobrará dentro de diez, aunque cambie de pasarela tres veces.

Domain-Driven Design parte del dominio (el negocio completo) y lo divide en subdominios: partes del problema con su propio modelo y su propio lenguaje. Suele producir fronteras muy parecidas a las capacidades de negocio, pero con dos aportaciones adicionales:

• Distingue subdominios core (donde la empresa compite), de soporte y genéricos, lo que ayuda a decidir dónde invertir esfuerzo de diseño.
• Detecta que una misma palabra ("producto", "cliente") significa cosas distintas en subdominios distintos, y que esa diferencia de significado es una costura.

En esta lección usamos DDD solo como estrategia de corte; la definición rigurosa de los bounded contexts de TechCorp, el lenguaje ubicuo y el mapa de contextos son el contenido de 02-03.

Es una decisión de granularidad dentro de cualquiera de las anteriores:

Para TechCorp la elección es sustantivos como base (pedidos, productos, stock, pagos, clientes) y el flujo "hacer un pedido" repartido entre ellos mediante eventos, sin un servicio "checkout" separado. La razón se verá con detalle en 02-05: el flujo se coordina por coreografía y servicio-pedidos es dueño del estado del pedido, no de las operaciones de los demás. Si el flujo se complicase (devoluciones parciales, pedidos con varios envíos), un servicio orquestador sería el momento de reconsiderarlo.

A veces se corta según quién va a mantener qué. Es la Ley de Conway usada a propósito (02-01, apartado 9): si Pagos y Notificaciones van a ser del mismo equipo, ¿deben ser un servicio o dos? La respuesta de TechCorp es dos, porque tienen ritmos de cambio y perfiles de riesgo distintos (Pagos toca dinero y una pasarela externa; Notificaciones toca plantillas y proveedores de correo), pero es legítimo que la organización influya en la granularidad final.

Las estrategias dicen cómo pensar; las técnicas dicen dónde mirar. TechCorp usa tres, de más conversacional a más mecánica.

Es un taller en el que negocio y técnicos reconstruyen el dominio en una pared con notas adhesivas. En su versión mínima:

1. Eventos de dominio (naranja): hechos relevantes en pasado. "Pedido creado", "Stock reservado", "Pago confirmado", "Correo enviado", "Producto publicado", "Precio cambiado", "Cliente registrado", "Stock repuesto".
2. Comandos (azul): la intención que provoca el evento. "Crear pedido", "Reservar stock", "Cobrar".
3. Actores y sistemas externos (amarillo / rosa): cliente, operario de almacén, pasarela de pago, proveedor de correo.
4. Se ordenan en una línea temporal y se buscan eventos pivote: aquellos tras los cuales cambia el vocabulario y cambian las personas que hablan.

Lo que se descubre para TechCorp, resumido:

Los grupos de eventos que comparten vocabulario y actor son los candidatos a servicio; las flechas discontinuas entre grupos son los eventos que cruzarán fronteras (los pedido.creado, stock.reservado, pago.confirmado, pedido.confirmado y pedido.cancelado de 01-05 salen literalmente de esta pared). Fíjate en que aparecen dos eventos que aún no habíamos nombrado, "Stock liberado" y "Pago reembolsado": son las compensaciones que necesitará la saga de 02-05. El taller también revela que "Precio cambiado" no interesa a Pedidos (un pedido guarda el precio del momento de la compra), lo que anticipa una decisión de datos de 02-03.

La segunda técnica es mecánica: quién importa a quién dentro del repositorio del monolito. Un grafo de require/import (herramientas como madge o dependency-cruiser lo generan en segundos) muestra los módulos con muchas dependencias entrantes (difíciles de extraer porque todos los usan) y salientes (difíciles de extraer porque usan a todos).

Resumen de lo que ve el equipo de Luis en techcorp-shop:

La lección de esta tabla: en un monolito con base de datos compartida, el grafo de require engaña. Los módulos parecen independientes porque el acoplamiento real pasa por las tablas. De ahí la tercera técnica.

Se construye una matriz tabla × área marcando quién lee (L) y quién escribe (E) cada tabla, a partir del código SQL del monolito. Para el esquema de 01-05:

Cómo se lee:

• Una tabla con una sola E y ninguna L ajena (atributos_producto, notificaciones) es una costura limpia: se extrae con su área sin tocar nada más.
• Una tabla con una E propia y varias L ajenas (clientes, productos, pedidos) se extrae con su dueño; las lecturas ajenas se convierten en llamadas al contrato o en copias de solo lectura (02-04).
• Una tabla con dos E (stock, pagos) es un problema de diseño, no solo de extracción: hoy crearPedido escribe en tablas de Inventario y de Pagos. Antes de extraer hay que devolver la escritura a su dueño (Pedidos pedirá a Inventario que reserve, no reservará él). Esa es la primera refactorización que hará el equipo de Luis dentro del monolito, antes de mover nada.

Esta matriz es la herramienta más valiosa de toda la lección: convierte "creo que pedidos está muy acoplado" en "pedidos escribe en dos tablas ajenas y lee otras dos", que es algo sobre lo que se puede planificar.

Una vez decidido qué extraer, hace falta cómo hacerlo con la tienda funcionando. Dos técnicas cubren la mayoría de casos. Aquí las presentamos como herramientas de descomposición; el relato completo de la migración de TechCorp, paso a paso, está en 08-01.

Se coloca una fachada (en TechCorp, el API Gateway del puerto 8080) delante del monolito. Al principio, todo el tráfico va al monolito. Cuando un servicio nuevo está listo, la fachada redirige solo sus rutas al servicio; el resto sigue yendo al monolito. Poco a poco, el monolito recibe menos rutas hasta quedar vacío y apagarse.

Ventajas: reversible (si el servicio nuevo falla, la fachada vuelve a apuntar al monolito), incremental y visible para el negocio (cada ruta migrada es un hito). Requisito: la fachada debe existir antes de la primera extracción, lo que la convierte en el primer entregable técnico del plan.

Sirve para las dependencias internas que la fachada no ve: por ejemplo, crearPedido obtiene precios leyendo la tabla productos. No se puede redirigir "por ruta"; hay que cambiar el código del monolito. La técnica:

1. Introducir una abstracción delante de la funcionalidad (una interfaz RepositorioProductos).
2. Hacer que el código existente la use (la implementación inicial sigue leyendo la tabla).
3. Escribir una segunda implementación que use el nuevo servicio (cliente HTTP de servicio-catalogo).
4. Conmutar entre ambas con configuración (una feature flag), primero en pruebas, luego en producción, con vuelta atrás inmediata si algo falla.
5. Borrar la implementación antigua.

Fíjate en que ambas implementaciones devuelven la misma forma (productoId, nombre, precio): esa forma es el embrión del contrato del catálogo, y hacerla explícita dentro del monolito es ya un paso de descomposición aunque no se haya movido una sola línea de servidor.

No todos los servicios se extraen a la vez ni en cualquier orden. TechCorp puntúa cada candidato en tres ejes:

• Valor: cuánto alivia un problema real de los cinco de 01-05 (escalado en campañas, despliegues, incidentes que se propagan, modelo de datos forzado, equipos que se pisan).
• Riesgo: cuánto negocio se pone en juego si la extracción sale mal, y cuánta lógica delicada (dinero, identidad) se toca.
• Dependencias: cuántas áreas dependen de él (entrantes) y de cuántas depende (salientes). Pocas dependencias, extracción fácil.

Tres razones resumen por qué el catálogo va primero: es donde está el problema más caro (las caídas de campaña), es la extracción con menos riesgo (no toca dinero ni el flujo de pedido en su camino crítico) y no depende de nadie: solo Pedidos depende de él para dos campos, y eso se resuelve con la abstracción del apartado 4.2. Extraerlo primero da además una victoria temprana que justifica la inversión ante Marta y entrena al equipo de plataforma en el pipeline completo (Docker, Kubernetes, canary) con el servicio menos peligroso.

Y una razón por la que pedidos no va primero aunque sea el core: extraer primero el servicio que depende de todos obligaría a construir seis contratos a la vez o a que servicio-pedidos siguiera leyendo la base de datos del monolito, es decir, a nacer como monolito distribuido.

Todo monolito tiene código que "usa todo el mundo". En techcorp-shop: bd/conexion.js, servicios/correo.js, servicios/pasarelaPago.js, además de utilidades menores (registro de logs, validación de peticiones, formato de errores). Hay cuatro destinos posibles, y elegir mal crea acoplamiento nuevo:

La regla que TechCorp adopta: se comparte código técnico como librería versionada; el código de negocio no se comparte, se convierte en un servicio o se duplica conscientemente. Duplicar un DTO de 5 campos en dos servicios es barato; compartirlo cuesta la autonomía de ambos.

Aplicamos todo lo anterior. El plan de descomposición de TechCorp:

Paso 1. Inventario del monolito. Carpetas, módulos y tablas (01-05), y matriz tabla × área (3.3).

Paso 2. Corte por capacidad de negocio, validado con los grupos de eventos del event storming (3.1) y con la matriz de tablas: seis capacidades, seis servicios. Coincide con las seis áreas funcionales, con dos matices que la matriz ha destapado: la reserva de stock la hará Inventario (hoy la hace crearPedido) y el registro del pago lo hará Pagos (hoy lo hace crearPedido).

Paso 3. Reparto de código y datos (los datos se detallan en 02-04; aquí, la asignación):

Paso 4. Diagrama de dependencias antes y después.

Antes: todos los módulos dependen de todas las tablas a través de un único pool de conexión. El grafo es, en la práctica, completo.

Después: cada servicio depende solo de su almacenamiento; entre servicios solo hay contratos (flechas continuas: llamadas síncronas a la API) y eventos (flechas discontinuas: publicación/suscripción). El cómo de esas flechas es el módulo 3.

Compara los dos grafos con la tabla de acoplamientos de 02-01: en el primero, todo es acoplamiento de datos y de despliegue; en el segundo, solo hay acoplamiento de contrato (dos llamadas síncronas de Pedidos) y de eventos. Queda un acoplamiento temporal deliberado (Pedidos consulta Catálogo y Clientes de forma síncrona al crear el pedido); en 02-04 veremos la alternativa de replicar esos datos y en 06-03 cómo proteger esas llamadas.

Paso 5. Orden y técnica de extracción. Catálogo (strangler por rutas /productos + branch by abstraction para los precios en crearPedido), Inventario (branch by abstraction para la reserva), Notificaciones (el monolito empieza a publicar eventos y el servicio los consume), Pagos (branch by abstraction para pasarelaPago), Pedidos (strangler de /pedidos, ya con la saga de 02-05) y Clientes (strangler de /clientes; el monolito se apaga).

• Cortar por carpetas del repositorio. Las carpetas reflejan cómo se organizó el código hace años, no las costuras de negocio. Usa la matriz de tablas: no miente.
• Fiarse solo del grafo de require. En un monolito con BD compartida, el acoplamiento está en el SQL. Un módulo sin dependencias de código puede escribir en cuatro tablas ajenas.
• Extraer el core primero "porque es lo importante". Es lo que depende de todos; extraerlo primero obliga a nacer acoplado. Empieza por lo que no depende de nadie y aporta valor visible.
• Convertir las utilidades en una gran librería compartida. Cada actualización de la librería redespliega a todos: es acoplamiento de despliegue en estado puro. Solo código técnico, versionado, y cada servicio decide cuándo actualizar.
• Extraer sin fachada. Sin gateway no hay strangler fig ni marcha atrás barata. El gateway es la primera pieza, no la última.
• Consejo: antes de mover código a un servicio nuevo, arregla el acoplamiento dentro del monolito (devuelve las escrituras a su dueño, introduce las abstracciones). Un monolito bien modularizado se descompone en semanas; uno enredado, en años.

Con la matriz tabla × área del apartado 3.3: (a) ¿qué dos tablas exigen una refactorización dentro del monolito antes de poder extraer su servicio, y en qué consiste? (b) ¿Qué tabla es la de extracción más limpia y por qué? (c) Notificaciones lee clientes y pedidos; ¿cómo obtendrá esos datos cuando sea un servicio, sin leer tablas ajenas?

Marta quiere añadir "promociones" (cupones de descuento, el caso de 01-03) durante la migración. Aplica los criterios de valor, riesgo y dependencias y decide: ¿se construye directamente como servicio-promociones o se añade primero al monolito? ¿En qué posición del orden de extracción encajaría? Justifica en 5-8 líneas.

Escribe el esqueleto (sin implementar detalles) de la abstracción que permitiría a crearPedido dejar de escribir en stock y pasar a pedir la reserva a servicio-inventario, con conmutación por configuración. Define el contrato de la abstracción (nombre del método, entrada, salida) e indica qué devolvería cada implementación cuando no hay stock.

Ejercicio 1

(a) stock y pagos: ambas tienen dos escritores. crearPedido reserva y descuenta stock, e inserta en pagos. Antes de extraer Inventario y Pagos, hay que mover esa lógica a sus módulos dueños dentro del monolito (por ejemplo, almacen.reservar(...) y pagos.registrarCobro(...)), de modo que crearPedido solo invoque y no escriba. Después, esas invocaciones se sustituyen por llamadas al servicio con branch by abstraction. (b) atributos_producto (y notificaciones): un solo escritor, ningún lector ajeno. Se extrae con Catálogo sin que nadie más se entere; además, su modelo clave-valor es la razón para llevar el catálogo a MongoDB. (c) Recibiéndolos en el evento: pedido.confirmado incluirá el pedidoId, el total y los datos mínimos del cliente necesarios para el correo (email, nombre) que servicio-pedidos habrá obtenido por contrato de Clientes. Alternativamente, Notificaciones podría consultar GET /clientes/{id} al recibir el evento; ambas opciones se comparan en 02-04. Lo que no hará nunca es SELECT sobre clientes.

Ejercicio 2

Valor: medio-alto para negocio (campañas), pero no resuelve ninguno de los cinco problemas de 01-05. Riesgo: bajo en sí mismo, pero alto por el momento: añadir un servicio nuevo mientras se migra el core duplica el frente de trabajo. Dependencias: promociones necesitaría conocer productos (a qué se aplica) y pedidos (dónde se aplica), es decir, depende de dos servicios que aún no están extraídos. Decisión razonable: construirlo dentro del monolito como un módulo bien aislado (su propia tabla cupones, una abstracción Promociones.calcularDescuento(lineas) que use crearPedido), respetando desde el primer día los principios de 02-01 para que su extracción posterior sea trivial. Encajaría en el orden entre Pagos y Pedidos (posición 4-5): después de que existan Catálogo e Inventario (sus dependencias) y antes de que Pedidos se extraiga con la saga definitiva, para que el campo descuentoAplicado de pedido.confirmado nazca ya en el contrato. Si el negocio no lo necesita con urgencia, mejor aún: después de Pedidos, con el sistema estable.

Ejercicio 3

Lo esencial: las dos implementaciones devuelven la misma forma en éxito y en fallo ({ ok, reservaId } / { ok: false, motivo }), de modo que crearPedido no distingue de dónde viene la reserva; y la abstracción incluye ya la operación inversa (liberar), porque en cuanto la reserva salga de la transacción única, harán falta compensaciones (02-05).

Descomponer un monolito es un trabajo de análisis antes que de código. Hemos visto las estrategias (capacidad de negocio como base, subdominios de DDD como refinamiento, sustantivos frente a verbos para ajustar granularidad, equipos como último ajuste), las técnicas para descubrir costuras (event storming, grafo de dependencias del código y, la más reveladora en un monolito con BD compartida, la matriz de acoplamiento tabla × área, que ha destapado que crearPedido escribe en stock y pagos sin ser su dueño), las técnicas de extracción segura (strangler fig tras el gateway y branch by abstraction con conmutación por configuración) y los criterios de orden (valor, riesgo, dependencias) que colocan al catálogo primero y a pedidos y clientes al final. También hemos decidido el destino de las utilidades compartidas: código técnico como librería versionada; código de negocio como servicio (correo.js → servicio-notificaciones, pasarelaPago.js → servicio-pagos) o duplicado a conciencia. El resultado es el plan de TechCorp: seis servicios, cada uno con sus módulos y sus tablas, y un grafo de dependencias que ha pasado de "todos contra todas las tablas" a "contratos y eventos".

Ese plan tiene todavía fronteras dibujadas a trazo grueso. La siguiente lección las afina con DDD estratégico: definiremos los bounded contexts de TechCorp, veremos por qué "producto" y "cliente" no significan lo mismo en cada contexto, dibujaremos el mapa de contextos con sus patrones de relación y decidiremos qué es un agregado (y por qué el stock no forma parte del agregado Pedido).