Marta ha tomado la decisión y Luis tiene el encargo de ejecutarla. Antes de dibujar un solo servicio, el equipo necesita un conjunto de principios de diseño compartidos: reglas sencillas que sirvan para juzgar cada decisión ("¿este límite es bueno?", "¿esta llamada está bien puesta?", "¿este servicio es demasiado pequeño?"). Sin principios explícitos, cada desarrollador diseñará según su intuición y el resultado será el monolito distribuido contra el que ya nos previno la lección 01-04.

Esta lección presenta los diez principios que guiarán todo el módulo 2 y, en realidad, todo el curso: cohesión y acoplamiento, responsabilidad única, autonomía, contrato como única puerta, datos descentralizados, diseño para el fallo, tamaño adecuado, Ley de Conway, smart endpoints, dumb pipes y automatización. Para que no se queden en teoría, cada principio se aplica al monolito de TechCorp y, al final, volvemos sobre los seis problemas que anotamos en crearPedido en la lección 01-05 para clasificarlos según el principio que violan. La descomposición en sí (qué servicios salen del monolito) es el tema de 02-02, y la definición de sus fronteras, el de 02-03: aquí fijamos el criterio con el que las juzgaremos.

1. Por qué empezar por principios y no por cajas
2. Alta cohesión y bajo acoplamiento: los cuatro tipos de acoplamiento
3. Responsabilidad única y modelado en torno a capacidades de negocio
4. Autonomía y despliegue independiente
5. El contrato como única puerta: ocultar los detalles internos
6. Datos descentralizados (enunciado)
7. Diseño para el fallo (enunciado)
8. Tamaño adecuado: "micro" no significa diminuto
9. La Ley de Conway aplicada a los equipos de TechCorp
10. Smart endpoints, dumb pipes
11. La automatización como principio de diseño
12. Radiografía de crearPedido: qué principio rompe cada problema

Cuando un equipo decide "hacer microservicios", la tentación inmediata es abrir una pizarra y dibujar cajas. El problema es que las cajas se dibujan solas: seis áreas del monolito, seis servicios, listo. Lo que no se dibuja solo es la calidad de las fronteras entre esas cajas, y ahí es donde un sistema distribuido triunfa o fracasa.

Los principios sirven para tres cosas:

• Decidir con criterio cuando el dominio no es evidente. En TechCorp, ¿la reserva de stock pertenece a Inventario o a Pedidos? ¿Las direcciones de envío son de Clientes o de Pedidos? Los principios dan la respuesta razonada; la intuición, no.
• Revisar diseños ajenos con un vocabulario común. Cuando Luis revise el diseño del equipo de Pagos, quiere poder decir "esto introduce acoplamiento temporal", no "esto no me gusta".
• Detectar la deriva con el tiempo. Los sistemas se degradan por acumulación de pequeñas excepciones ("solo esta vez leo la tabla de otro servicio"). Los principios son la línea contra la que medir la deriva.

Los principios que siguen no son un invento del curso: proceden del trabajo de Sam Newman, Martin Fowler, James Lewis, Chris Richardson y la comunidad de DDD. Lo que hacemos aquí es ordenarlos y aterrizarlos en la tienda de TechCorp.

Es el principio madre; todos los demás son formas de conseguirlo.

• Cohesión: las cosas que cambian juntas deben vivir juntas. Si cada vez que cambia una regla de negocio hay que tocar tres servicios, la cohesión es baja.
• Acoplamiento: el grado en que un cambio en un servicio obliga a cambiar (o afecta al funcionamiento de) otro. Queremos que sea el mínimo imprescindible.

La frase clásica es "cambiar una cosa debería requerir tocar un solo servicio y desplegar solo ese servicio". En el monolito de TechCorp ocurre lo contrario: cuando Notificaciones cambió una consulta sobre pedidos, rompió un informe de Pedidos (problema 3 de 01-05).

Acoplamiento no es una sola cosa. Distinguir sus tipos es lo que permite atacarlo:

Dos observaciones importantes:

• El acoplamiento de contrato es el bueno. Dos servicios que se comunican tienen que compartir algo: la forma del mensaje. El objetivo del diseño es que ese sea el único acoplamiento y que sea explícito, pequeño y estable.
• El acoplamiento temporal es el más traicionero, porque no se ve en el código: una cadena de llamadas HTTP síncronas parece limpia y modular, pero si cinco servicios se llaman en cadena, la disponibilidad del conjunto es el producto de las cinco (0,99⁵ ≈ 0,95) y la latencia, la suma. Un ejemplo esquemático:

Este código "hace microservicios" y, sin embargo, reproduce exactamente el defecto del monolito: la caída del correo sigue impidiendo vender. Fíjate en que el último await es indefendible desde el punto de vista del negocio: un pedido cobrado es un pedido, se haya enviado el correo o no. Los principios sirven precisamente para detectar esto antes de escribirlo.

Un microservicio debe tener una razón para cambiar, y esa razón debe ser una capacidad de negocio: algo que la empresa hace y que un responsable de negocio reconocería en una frase ("gestionar el catálogo", "cobrar pedidos", "avisar al cliente").

Lo que no es una buena unidad de responsabilidad:

En TechCorp, las seis áreas funcionales de 01-05 (clientes, catálogo, inventario, pedidos, pagos, notificaciones) son capacidades de negocio reconocibles: cada una tiene un responsable de negocio distinto, un vocabulario propio y un ritmo de cambio propio (el catálogo cambia a diario; las reglas de cobro, unas pocas veces al año). Es una señal de que el corte va bien encaminado, aunque en 02-03 afinaremos las fronteras con más rigor.

Una prueba rápida que usará Luis: "¿Puedo explicar qué hace este servicio en una frase sin usar la palabra 'y'?". "Gestiona el stock y las reservas" pasa (reservar es parte de gestionar stock). "Crea pedidos y envía correos" no pasa.

Un servicio es autónomo cuando su equipo puede cambiarlo, probarlo y desplegarlo sin pedir permiso ni coordinarse con otros equipos, y cuando puede seguir funcionando (aunque sea de forma degradada) si otros no están.

La autonomía tiene tres caras:

1. Autonomía de código: repositorio o, al menos, módulo con propietario claro y pipeline propio.
2. Autonomía de datos: nadie más lee ni escribe su almacenamiento (principio 6).
3. Autonomía de ejecución: no depende de que otro servicio esté vivo para responder a las peticiones que puede resolver por sí solo.

La prueba de fuego es el despliegue independiente: si para poner en producción servicio-catalogo v2.3 hay que desplegar a la vez servicio-pedidos, no hay autonomía, hay un monolito repartido en varios procesos. Es el problema 1 de TechCorp (despliegues semanales con miedo, 4 de 12 revertidos): el despliegue de jueves noche existe porque nada se puede desplegar por separado.

Autonomía no significa aislamiento total: los servicios colaboran. Significa que la colaboración se hace a través de contratos estables (principio 5) y que la disponibilidad de uno no arrastra a los demás (principio 7).

Un microservicio expone un contrato (una API HTTP, un conjunto de eventos publicados, o ambos) y todo lo demás es privado: sus tablas, sus colecciones, sus ficheros, su estructura interna de módulos, sus decisiones tecnológicas. Es la aplicación a escala de sistema del encapsulamiento que ya conoces de la programación orientada a objetos.

Consecuencias directas:

• Ningún servicio accede a la base de datos de otro. Ni para leer. Ni "solo un informe".
• Ningún servicio importa código de negocio de otro (require('../../servicio-catalogo/modelos/producto') es una violación).
• Un servicio puede cambiar su tecnología interna (de PostgreSQL a MongoDB, como hará el catálogo) sin que nadie se entere.
• El contrato es lo único que hay que versionar y proteger (03-06).

Compara las dos formas de que Pedidos sepa el precio de un producto:

Fíjate en el detalle: en la segunda versión, servicio-pedidos no sabe que el catálogo tiene una columna activo ni que existe una tabla productos. Solo conoce el contrato. Cuando en 02-04 el catálogo se mude a MongoDB, esta línea no cambiará.

Una consecuencia menos evidente: el contrato debe expresar operaciones de negocio, no operaciones de datos. POST /reservas ("reserva estas cantidades para este pedido") es un contrato de negocio; PATCH /stock/{id} con { reservado: 7 } es exponer la tabla por HTTP, y obliga a los llamantes a conocer la lógica interna del inventario (que reservado no puede superar cantidad, por ejemplo).

Cada servicio es dueño exclusivo de sus datos: decide su esquema, su tecnología y su ciclo de vida, y es el único que los escribe. Los demás servicios obtienen esos datos a través del contrato (consultando la API o suscribiéndose a los eventos que publica el propietario), nunca leyendo su almacenamiento.

Es el principio que más resistencia genera, porque tiene un coste real: se pierden los JOIN entre áreas y se pierde la transacción única. En TechCorp, es exactamente lo que hace crearPedido: una transacción que toca clientes, productos, stock, pedidos, lineas_pedido y pagos. La lección 02-04 desarrolla el patrón database-per-service, cómo se rompen las claves foráneas cruzadas y qué alternativas hay para las consultas que hoy son un JOIN; la 02-05 sustituye la transacción por una saga. Aquí basta con fijar la regla: una tabla, un dueño.

En un monolito, una llamada a función no falla por la red. En un sistema distribuido, toda interacción entre servicios puede fallar, tardar más de lo esperado o ejecutarse dos veces. Las ocho falacias de la computación distribuida de 01-02 son la lista de lo que no se puede asumir.

Diseñar para el fallo significa, desde la fase de diseño:

• Decidir qué hace cada servicio cuando su dependencia no responde: ¿falla?, ¿responde con datos cacheados?, ¿encola el trabajo para más tarde?
• Asumir que los mensajes pueden llegar duplicados y diseñar operaciones idempotentes.
• Establecer timeouts en toda llamada saliente y no dejar nunca una petición esperando indefinidamente.
• Preferir la degradación parcial al fallo total: si Notificaciones cae, los pedidos deben seguir entrando.

Los mecanismos concretos (reintentos con backoff, circuit breakers, bulkheads, colas de mensajes fallidos) se estudian en 06-03. En este módulo, el principio se traduce en decisiones de diseño: qué interacciones son síncronas y cuáles asíncronas, y qué compensaciones existen cuando un paso de un flujo falla (02-05).

El prefijo "micro" ha hecho mucho daño. No existe un número de líneas de código, ni de tablas, ni de endpoints que defina el tamaño correcto. Los criterios útiles son otros:

La regla práctica: empezar con pocos servicios más grandes y dividir cuando haya una razón (escalado distinto, equipos distintos, ritmo de cambio distinto). Es mucho más barato partir un servicio que fusionar dos que se han diseñado por separado con contratos y bases de datos propias. Por eso TechCorp no tendrá servicio-reservas separado de servicio-inventario, ni servicio-lineas-pedido separado de servicio-pedidos.

Melvin Conway enunció en 1967 que las organizaciones diseñan sistemas que reflejan su estructura de comunicación. Si tres equipos construyen un compilador, saldrá un compilador de tres pasadas. Aplicado a microservicios: si los equipos están organizados por capa técnica (front, back, BD), saldrán servicios por capa técnica; si están organizados por capacidad de negocio, saldrán servicios por capacidad de negocio.

La consecuencia práctica es la maniobra inversa de Conway: decidir primero la arquitectura que se quiere y organizar los equipos para que la reflejen. En TechCorp, hoy hay un único equipo de desarrollo repartido informalmente por áreas, todos sobre el mismo repositorio; el 20 % de tiempo de coordinación del que se queja Luis es la Ley de Conway en acción.

La propuesta de Marta para acompañar la migración:

Observa dos decisiones:

• Ningún servicio tiene dos equipos dueños y ningún equipo tiene más servicios de los que puede mantener. Un servicio con dos dueños acaba con dos criterios de diseño; un equipo con seis servicios acaba descuidando cuatro.
• Existe un equipo de plataforma que no es dueño de negocio, sino de las herramientas comunes (clúster, pipelines, observabilidad). Es la forma de que la automatización (principio 11) no recaiga en cada equipo por separado.

Que Pedidos e Inventario compartan equipo no significa que compartan base de datos ni código: los principios 5 y 6 se aplican igual dentro de un equipo. Lo que comparten es ritmo y contexto: son las dos piezas que más conversan en el flujo de pedido y conviene que las conversaciones de diseño sean baratas.

Este principio, formulado por Fowler y Lewis, es una reacción a la época SOA que repasamos en 01-01: entonces, el Enterprise Service Bus (la "tubería") concentraba lógica de negocio: transformaciones, enrutado por contenido, orquestaciones complejas. El resultado era un bus inteligente rodeado de servicios tontos, y el bus se convertía en un monolito central que nadie se atrevía a tocar.

En microservicios se invierte:

• Los extremos son inteligentes: la lógica de negocio vive en los servicios. servicio-inventario decide si puede reservar; nadie decide por él.
• Las tuberías son tontas: HTTP y el broker de mensajes (RabbitMQ en el curso) transportan bytes. Enrutan, entregan, reintentan, pero no saben qué es un pedido.

Qué implica para el diseño de TechCorp:

Cuando en 05-05 aparezca el service mesh (Istio), veremos que también respeta este principio: la malla se ocupa de red, seguridad y observabilidad, nunca de lógica de negocio.

Puede sorprender que la automatización sea un principio de diseño y no de operaciones. La razón es que un diseño de seis, doce o veinte servicios es inviable sin automatización, y por tanto la automatización condiciona el diseño desde el primer día:

• Si el despliegue no es automático, nadie desplegará servicios de forma independiente y se volverá al "jueves por la noche".
• Si las pruebas de contrato no son automáticas, nadie se atreverá a cambiar un contrato.
• Si la creación de un servicio nuevo no está automatizada (plantilla, pipeline, panel de métricas), el coste de crear un servicio será tan alto que se meterá todo en los existentes.
• Si no hay observabilidad automática, un flujo repartido en cinco servicios será imposible de depurar.

Por eso el diseño de TechCorp incluye, como parte del sistema y no como añadido, GitHub Actions (05-03), Docker y Kubernetes (05-01, 05-02), Prometheus/Grafana/Loki (06-01) y OpenTelemetry (06-02). Y por eso existe el equipo de plataforma del apartado 9. La regla de Luis: "Si hay que hacerlo más de una vez por servicio, se automatiza antes de crear el segundo servicio".

En 01-05 anotamos seis problemas en el código de crearPedido. Ahora podemos clasificarlos con precisión, y esa clasificación es el guion de las lecciones que vienen:

Y hay un séptimo problema que no anotamos entonces porque aún no teníamos vocabulario: el despliegue. crearPedido vive en el mismo artefacto que la búsqueda del catálogo, así que un cambio en cómo se ordenan los resultados de búsqueda obliga a redesplegar la lógica de cobro. Es acoplamiento de despliegue puro, viola la autonomía, y es lo que las lecciones del módulo 5 resuelven una vez que el diseño lo permite.

Este cuadro es el "contrato" del módulo 2 con el lector: al terminar 02-05, cada fila tendrá una solución diseñada.

• Confundir "principio" con "regla absoluta". Los principios se ponderan. A veces se acepta acoplamiento temporal (una consulta síncrona a Catálogo para mostrar precios) porque la alternativa (replicar todo el catálogo) es peor. Lo importante es que la excepción sea consciente y esté documentada.
• Buscar "microservicios pequeños" en lugar de "microservicios autónomos". El tamaño es una consecuencia, no un objetivo. Un servicio de 30 000 líneas que un equipo despliega diez veces al día sin coordinarse con nadie es un buen microservicio.
• Diseñar servicios y dejar los equipos como estaban. La Ley de Conway se impone siempre. Si un solo equipo mantiene seis servicios con seis repositorios, acabará desplegándolos juntos "para simplificar".
• Exponer la base de datos por HTTP. GET /stock/{id} que devuelve la fila tal cual y PATCH /stock/{id} para modificarla no es un contrato de negocio, es acoplamiento de datos disfrazado. Los contratos hablan de reservas, cobros y pedidos.
• Dejar la automatización "para después". Después nunca llega, y sin ella el segundo servicio ya duele.
• Consejo: escribe los principios en una página del wiki del equipo, con un ejemplo de TechCorp por principio, y úsalos como lista de comprobación en cada revisión de diseño. Es lo que hará Luis a partir de esta semana.

Para cada situación del monolito de TechCorp, indica qué tipo(s) de acoplamiento describe (temporal, de despliegue, de datos, de contrato) y qué principio se está violando:

1. Cuando Pedidos añadió una columna a lineas_pedido, la migración falló por un bloqueo con una consulta pesada de Catálogo.
2. Un cambio en la plantilla del correo de confirmación obliga a ejecutar la suite completa de 40 minutos y a desplegar el jueves.
3. Si la pasarela de pago tarda 8 segundos en responder, la petición POST /pedidos tarda 8 segundos y las filas de stock quedan bloqueadas mientras tanto.
4. El módulo de informes importa directamente controladores/pedidosControlador.js para reutilizar una función que calcula totales.

Aplica la prueba "¿puedo describirlo en una frase sin 'y'?" a estos candidatos a servicio y decide si son una capacidad de negocio válida, un servicio demasiado grande o un nanoservicio. Justifica en una línea:

1. servicio-calculo-iva
2. servicio-inventario (stock, reservas, liberaciones, entradas de almacén)
3. servicio-pedidos-y-facturacion
4. servicio-notificaciones (correos y SMS a partir de eventos)

Marta propone una organización alternativa: un equipo "Back-end" (todos los servicios), un equipo "Front-end" y un equipo "Datos" (todas las bases de datos). Explica en 4-6 líneas qué arquitectura predice la Ley de Conway para esa organización y por qué es incompatible con los principios 4, 5 y 6.

Ejercicio 1

1. Acoplamiento de datos (dos áreas sobre el mismo esquema físico) con efecto de despliegue (la migración de una bloquea a la otra). Viola datos descentralizados y autonomía.
2. Acoplamiento de despliegue: un cambio trivial de una capacidad arrastra el despliegue de todas. Viola autonomía y despliegue independiente; de fondo, automatización (una suite de 40 minutos no permite despliegues frecuentes).
3. Acoplamiento temporal con la pasarela, agravado por el acoplamiento de datos (bloqueo de stock, que es de otra área). Viola diseño para el fallo y datos descentralizados.
4. Acoplamiento de contrato implícito y no gestionado (depende de la firma interna de una función que no es un contrato público) y, en el fondo, viola el contrato como única puerta: los informes deberían consumir una API o un evento, no código interno de otra área.

Ejercicio 2

1. servicio-calculo-iva: nanoservicio. Es una función, no una capacidad; nadie en negocio diría "nuestra capacidad de calcular IVA". Debería ser una librería o parte de Pedidos/Pagos.
2. servicio-inventario: capacidad válida. "Gestiona el stock" (reservar y liberar son operaciones del stock). Un responsable de almacén lo reconoce.
3. servicio-pedidos-y-facturacion: demasiado grande o, al menos, dos capacidades con ritmos y responsables distintos (ventas vs. contabilidad). Candidato a dividirse en cuanto haya una razón (por ejemplo, requisitos fiscales que cambian sin tocar el ciclo del pedido).
4. servicio-notificaciones: capacidad válida. "Avisa al cliente de lo que ocurre" es una frase sin "y" (correo y SMS son canales de la misma capacidad, no capacidades distintas).

Ejercicio 3

La Ley de Conway predice una arquitectura por capas: un gran "back-end" (que tendería a ser un único servicio o un conjunto de servicios que se despliegan juntos porque un solo equipo los mantiene), un front-end aparte y una base de datos compartida gestionada por el equipo de Datos, con esquemas diseñados por ese equipo para todos. Es incompatible con la autonomía (ningún equipo puede desplegar una capacidad de negocio de punta a punta sin coordinarse con los otros dos), con el contrato como única puerta (el equipo de Datos accedería a todo y los servicios compartirían tablas por diseño) y con datos descentralizados (habría un dueño único de todas las bases de datos, es decir, la BD compartida de 01-01: un monolito distribuido). Para obtener microservicios autónomos, los equipos deben ser verticales por capacidad de negocio, con un equipo de plataforma horizontal solo para herramientas.

Hemos fijado el criterio con el que juzgaremos todo lo que diseñemos: alta cohesión y bajo acoplamiento (distinguiendo acoplamiento temporal, de despliegue, de datos y de contrato), responsabilidad única en torno a capacidades de negocio, autonomía con despliegue independiente, el contrato como única puerta, datos descentralizados, diseño para el fallo, tamaño adecuado (equipos de dos pizzas, "que quepa en la cabeza"), Ley de Conway aplicada a los cuatro equipos de TechCorp, smart endpoints, dumb pipes y automatización desde el diseño. Y hemos vuelto sobre crearPedido para clasificar sus seis problemas (más el de despliegue) según el principio que rompen: baja cohesión, acoplamiento de datos, transacción única, acoplamiento temporal con la pasarela y con el correo, y falta de idempotencia.

Con estos principios como lista de comprobación, la siguiente lección aborda la primera gran pregunta práctica: cómo se descompone el monolito. Veremos las estrategias (por capacidad de negocio, por subdominio, por casos de uso, por equipos), las técnicas para descubrir las costuras (incluido el análisis de acoplamiento del esquema SQL de 01-05), las técnicas de extracción segura y, sobre todo, en qué orden extraerá TechCorp sus seis servicios y por qué el catálogo va primero.