Compara un monolito modular con una separación de Sales, Payments e Inventory. Diseña contratos en TypeScript y Express y comprende fallos parciales, consistencia eventual, idempotencia, Outbox y Sagas sin introducir infraestructura compleja.
Sales, Payments e Inventory están en procesos distintos. Sin embargo, cada compra llama a los tres en cadena, todos leen las mismas tablas y cualquier cambio exige desplegar todo el sistema.
Tenemos una aplicación distribuida, pero poca autonomía.
La alternativa tampoco es decidir que los microservicios siempre son un error. Quizá Payments necesita un ciclo de entrega independiente, Inventory tiene una carga distinta y los equipos pueden operar esas capacidades por separado.
La pregunta es qué beneficio concreto justifica introducir límites de despliegue y comunicación por red, y qué responsabilidades nuevas tendremos que asumir.
En este artículo partiremos de un monolito modular y exploraremos una separación posible. Los diagramas y ejemplos son propuestas didácticas, no una recomendación de migrar nuestra tienda real.
Una arquitectura de microservicios organiza la aplicación en servicios desplegables independientemente y orientados a capacidades. Esa independencia necesita contratos y límites operativos; no aparece solo al dividir un repositorio.
Lewis y Fowler describen características habituales como organización por capacidades del negocio, despliegue independiente y gestión descentralizada de datos. No proponen medir un microservicio por una cantidad fija de líneas. Microservices.
Las ventajas potenciales incluyen evolucionar o escalar capacidades de manera diferenciada. Los costes incluyen comunicación remota, más elementos operativos y resultados parciales.
«Potencial» importa: extraer código puede aumentar el coste sin obtener independencia si conserva dependencias que obligan a coordinar cada cambio.
Bounded Context: delimita un modelo y su significado.
Módulo: organiza responsabilidades dentro del código.
Aggregate: protege decisiones y consistencia dentro de un modelo.
Microservicio: introduce una unidad de ejecución, despliegue y operación.
Un contexto puede implementarse con varios módulos y agregados. Puede vivir dentro de un monolito o distribuir ciertas capacidades en más de un servicio cuando exista una razón.
No hay una regla de «un agregado, un microservicio» ni «un contexto, un servidor». Mantener coherencia del modelo y evitar fragmentación innecesaria siguen siendo decisiones de diseño.
La guía de Microsoft recomienda comenzar con el dominio y contrastar candidatos con necesidades de equipo, datos, disponibilidad y escala, revisando separaciones y agrupaciones. Eso orienta el análisis; no convierte cada candidato del modelo en un servicio obligatorio. Identificar límites de microservicios.
Nuestra tienda mantiene un despliegue con responsabilidades separadas:
Aplicación commerce
|
+-- Sales
| +-- modelo de pedidos
| +-- casos de uso
| +-- adaptadores
|
+-- Payments
| +-- modelo de pagos
| +-- casos de uso
| +-- adaptadores
|
+-- Inventory
+-- modelo de existencias y reservas
+-- casos de uso
+-- adaptadores
La separación debe reflejarse en dependencias y propiedad de datos. Una carpeta por contexto no basta si Sales escribe directamente las tablas de Payments.
Un monolito modular puede tener contratos explícitos entre contextos. En los ejemplos de la colección, las integraciones se expresan mediante ACL HTTP y contratos del consumidor, sin imports de entidades ajenas.
Si la llamada HTTP apunta al mismo despliegue, todavía necesita manejar errores. La ubicación física no crea una transacción compartida.
Mantener un despliegue puede simplificar operación y entrega para un equipo pequeño. No impide modelar límites que después podamos revisar.
Supongamos estas necesidades, todavía por confirmar:
La separación sería candidata si esas condiciones se sostienen con evidencia.
Antes de aprobarla, pregunta:
Si la única respuesta es «queremos algo moderno», falta una razón de negocio u operación.
Cliente
|
v
Sales Service -------------------> Inventory Service
| |
| datos Inventory
|
+------------------------------> Payments Service
| |
| datos Payments
|
datos Sales
Payments -- contrato de PaymentConfirmed --> Sales
Las flechas de consulta y los hechos publicados representan contratos distintos. El dibujo no requiere un broker concreto ni describe toda la coordinación de compra.
Una estructura de proyectos podría ser:
services/
sales/
src/domain/
src/application/
src/adapters/
payments/
src/domain/
src/application/
src/adapters/
inventory/
src/domain/
src/application/
src/adapters/
Cada servicio puede elegir una organización interna adecuada. No repetiremos aquí las capas del artículo anterior; distribuir procesos no sustituye la protección de sus reglas.
Tampoco son obligatorios repositorios separados o lenguajes diferentes. Introducir herramientas distintas sin necesidad añade mantenimiento, no autonomía por definición.
Sales mantiene pedidos. Payments mantiene pagos e intentos. Inventory mantiene reservas y existencias.
Un servicio no debería escribir las tablas de otro para evitar una llamada. Tampoco debería depender de su esquema mediante joins operativos.
La propiedad de datos puede implementarse con bases o esquemas separados y permisos adecuados. Compartir una instancia física no equivale necesariamente a compartir propiedad, pero deben conservarse los controles y la independencia de cambios.
Si todos pueden consultar y modificar cualquier tabla, la separación de procesos pierde buena parte de su propósito.
Los informes que necesitan combinar información requieren un diseño explícito. Una consulta administrativa no justifica abrir indiscriminadamente el almacenamiento operativo de cada servicio.
Sales consulta disponibilidad:
GET /integration/v1/availability/BAG-URBAN
Accept: application/json
Inventory responde:
{
"sku": "BAG-URBAN",
"reservableQuantity": 8
}
La semántica es importante: observar ocho unidades no reserva ninguna. La cantidad puede cambiar antes de la siguiente operación.
El consumidor define un puerto y mantiene la interpretación del contrato en un adaptador. El siguiente ejemplo es de lectura y presupone Node.js con fetch y TypeScript configurado para sus APIs.
En inventory-availability.ts:
export interface Availability {
readonly sku: string;
readonly reservableQuantity: number;
}
export interface AvailabilityReader {
read(sku: string): Promise<Availability>;
}
export class InventoryUnavailableError extends Error {}
export class UnknownSkuError extends Error {}
export class InventoryContractError extends Error {}
export function parseAvailability(
raw: unknown,
expectedSku: string,
): Availability {
if (
typeof raw !== "object" ||
raw === null ||
Array.isArray(raw)
) {
throw new InventoryContractError();
}
const data = raw as Record<string, unknown>;
const quantity = data.reservableQuantity;
if (
data.sku !== expectedSku ||
typeof quantity !== "number" ||
!Number.isSafeInteger(quantity) ||
quantity < 0
) {
throw new InventoryContractError();
}
return { sku: expectedSku, reservableQuantity: quantity };
}
export class InventoryHttpAvailability implements AvailabilityReader {
constructor(
private readonly origin: string,
private readonly authenticationHeaders:
() => Promise<Record<string, string>>,
) {
const url = new URL(origin);
if (
url.protocol !== "https:" ||
url.username !== "" ||
url.password !== "" ||
url.pathname !== "/" ||
url.search !== "" ||
url.hash !== ""
) {
throw new Error("Origen de Inventory inválido");
}
}
async read(sku: string): Promise<Availability> {
if (!/^[A-Za-z0-9_-]{1,64}$/.test(sku)) {
throw new Error("SKU inválido");
}
const url = new URL(
"/integration/v1/availability/" + encodeURIComponent(sku),
this.origin,
);
const headers = await this.authenticationHeaders();
let response: Response;
try {
response = await fetch(url, {
headers: { ...headers, accept: "application/json" },
signal: AbortSignal.timeout(3000),
redirect: "error",
cache: "no-store",
});
} catch {
throw new InventoryUnavailableError();
}
if (response.status === 404) throw new UnknownSkuError();
if (!response.ok) throw new InventoryUnavailableError();
const raw: unknown = await response.json();
return parseAvailability(raw, sku);
}
}
La configuración del origen y las credenciales procede de fuentes administrativas controladas, no de una URL enviada por el usuario. El proveedor debe autenticar y autorizar esas llamadas.
El ejemplo fija un tiempo máximo didáctico y no sigue redirecciones. No implementa límites de tamaño de respuesta, observabilidad ni gestión completa de errores de JSON; deben tratarse antes de producción.
La parte importante es la distinción: servicio inaccesible no significa producto desconocido ni disponibilidad cero.
No hay reintentos automáticos. Incluso una lectura debe tener un presupuesto total de espera y una política que no multiplique carga cuando el proveedor falla.
Una reserva podría usar este contrato ilustrativo:
POST /integration/v1/reservations
Content-Type: application/json
{
"requestId": "checkout-100-reservation",
"sku": "BAG-URBAN",
"quantity": 2
}
Inventory debe definir qué significa repetir la solicitud, cómo la vincula al consumidor y qué ocurre si se reutiliza con otros datos.
Si se promete idempotencia, el registro de solicitud y el efecto deben coordinarse de forma durable y atómica. Un requestId en el JSON no implementa esa garantía.
Si Sales pierde la respuesta, no sabe automáticamente que la reserva falló. Puede necesitar consultar o repetir conforme al contrato, conservando la misma identidad lógica.
La disponibilidad de red cambia el diseño del caso de uso. Una función remota no es una función local más lenta.
Payments puede publicar una confirmación mediante el lenguaje de integración ya estudiado:
interface PaymentConfirmedV1 {
readonly type: "payment.confirmed";
readonly schemaVersion: 1;
readonly messageId: string;
readonly paymentId: string;
readonly orderId: string;
readonly amountMinor: number;
readonly currency: "EUR";
readonly status: "CONFIRMED";
readonly occurredAt: string;
}
El fragmento representa un contrato, no valida un mensaje de red. Mantiene el significado de la colección: captura completa registrada, importe bruto en céntimos de EUR e instante UTC de confirmación.
Un Domain Event interno puede originar esa información. El Integration Event selecciona una representación pública que los consumidores pueden interpretar sin importar el agregado de Payments.
El consumidor necesita verificar emisor, formato, identidad y correspondencia con su operación. No debe confirmar cualquier pedido solo porque reciba un documento con ese nombre.
La integración asíncrona permite que los servicios no tengan que estar disponibles en el mismo instante para procesar el trabajo, si el transporte conserva los mensajes adecuadamente. A cambio introduce retrasos, duplicados y posibles diferencias de orden que deben gestionarse.
Payments puede registrar el cobro mientras Sales todavía muestra «procesando confirmación». Durante ese intervalo, sus modelos no reflejan la misma información.
La consistencia eventual no significa que todo se resolverá mágicamente. Necesita mecanismos de entrega, procesamiento, reintento y resolución de operaciones que quedan atascadas.
La experiencia debe diferenciar pendiente, rechazado y desconocido. Ocultar un estado intermedio mostrando éxito antes de tiempo no mejora la consistencia.
Una API Express de Sales podría consultar una vista local del progreso, evitando llamar a todos los servicios cada vez que el usuario actualiza la pantalla.
Este fragmento usa Express 5 y dependencias obligatorias para lectura y autorización:
import express, { type Request } from "express";
interface OrderProgress {
readonly orderId: string;
readonly status: "PROCESSING" | "CONFIRMED" | "REQUIRES_REVIEW";
}
interface OrderProgressReader {
read(orderId: string): Promise<OrderProgress | null>;
}
export function createProgressApp(
progress: OrderProgressReader,
authorize: (request: Request, orderId: string) => Promise<void>,
) {
const app = express();
app.get("/orders/:id/progress", async (req, res) => {
const orderId = req.params.id;
if (
typeof orderId !== "string" ||
!/^[A-Za-z0-9_-]{1,64}$/.test(orderId)
) {
res.status(400).json({ error: "INVALID_ORDER_ID" });
return;
}
await authorize(req, orderId);
const result = await progress.read(orderId);
if (!result) {
res.status(404).json({ error: "ORDER_NOT_FOUND" });
return;
}
res.set("Cache-Control", "no-store").json({
orderId: result.orderId,
status: result.status,
});
});
return app;
}
El lector debe obtener datos de Sales, no de las tablas ajenas. La autorización debe verificar el permiso sobre el pedido. Se omite el middleware final de errores y no se arranca un servidor: no es una aplicación completa para producción.
La vista local tiene que actualizarse y permitir detectar estados demasiado antiguos. Leer localmente reduce una cadena de dependencias, pero no elimina el trabajo de integración.
Un problema clásico aparece al guardar un pago y después intentar publicar su confirmación. Puede funcionar la escritura y fallar la publicación.
Transactional Outbox registra el cambio y una notificación pendiente en la misma transacción local. Otro proceso entrega posteriormente el mensaje. Así se evita que una de esas dos escrituras locales quede comprometida sin la otra. AWS: Transactional Outbox.
Transacción local en Payments:
guardar confirmación
registrar mensaje pendiente en outbox
confirmar transacción
Después:
entregar mensaje pendiente
registrar progreso de entrega
Puede haber duplicados si la entrega se repite. El consumidor necesita una estrategia de idempotencia apropiada y durable.
Outbox no crea atomicidad entre las bases de Payments y Sales. Tampoco sustituye las reglas para ordenar o interpretar hechos distintos. Aquí solo introducimos su propósito; no implementamos el mecanismo.
Una compra puede requerir reservar, cobrar y confirmar. Si una parte falla, el negocio necesita decidir cómo continuar o compensar.
Una Saga organiza una secuencia de transacciones locales y acciones de recuperación o compensación. Puede coordinarse mediante un orquestador o mediante colaboración entre participantes. La documentación de AWS describe la alternativa orquestada y sus compromisos. Saga orchestration.
Liberar una reserva o solicitar un reembolso son acciones de negocio, no un rollback instantáneo de una transacción común. Pueden fallar, tardar o necesitar intervención.
No todas las operaciones son reversibles del mismo modo. Despachar un paquete no se deshace borrando una fila.
Antes de introducir una Saga, describe el resultado aceptable y quién resuelve cada situación. No es una palabra que pueda añadirse al diagrama para declarar consistencia.
Cuando una compra atraviesa servicios, necesitas relacionar lo ocurrido sin registrar secretos.
Mantén referencias de negocio y correlación técnica, estados de cada intento y señales de operaciones pendientes. Las trazas ayudan a seguir llamadas; las métricas muestran tendencias y los registros aportan contexto.
Distingue rechazos esperados de fallos técnicos. Un aumento de reservas rechazadas no necesariamente es una caída de Inventory.
Las pruebas también tienen niveles:
Por ejemplo, estas aserciones propuestas verifican únicamente el parser del cliente anterior. No se han ejecutado como parte del artículo:
import assert from "node:assert/strict";
import { parseAvailability } from "./inventory-availability.js";
assert.deepEqual(parseAvailability({
sku: "BAG-URBAN",
reservableQuantity: 0,
}, "BAG-URBAN"), {
sku: "BAG-URBAN",
reservableQuantity: 0,
});
assert.throws(() => parseAvailability({
sku: "OTHER",
reservableQuantity: 8,
}, "BAG-URBAN"));
assert.throws(() => parseAvailability({
sku: "BAG-URBAN",
reservableQuantity: "8",
}, "BAG-URBAN"));
También deben probarse pérdida de respuesta, mensajes repetidos y dependencias no disponibles. Un test verde con mocks no demuestra que todo el sistema pueda recuperarse.
Mantener un despliegue puede ser adecuado cuando los límites siguen cambiando, el equipo es pequeño o no existe una necesidad clara de entregas y operación independientes.
También puede ser la mejor opción si una separación produciría demasiadas llamadas para tomar cada decisión o si todavía no hay capacidad para mantener los servicios resultantes.
Un monolito con límites claros puede aportar más autonomía de código que varios servicios que comparten tablas y se despliegan siempre juntos.
Si existe un candidato justificado, extraer una capacidad de manera gradual permite comprobar el beneficio antes de fragmentar toda la aplicación. Hay que planificar propiedad de datos, transición y operación; evitar dos escritores sin un acuerdo explícito.
No conviene distribuir un acoplamiento que todavía no se entiende.
Revisa estas situaciones:
Una llamada remota puede cruzar una frontera coherente. Muchas llamadas para reconstruir una decisión pequeña pueden indicar un límite que necesita revisarse.
Una plataforma puede tener una capacidad de evaluación que necesita recursos y operación muy distintos de la gestión de cursos. Esa diferencia puede justificar estudiar un servicio separado si su contrato y sus fallos están claros.
No implica separar cada pregunta, intento y calificación en procesos distintos. La cohesión de la capacidad sigue importando.
Una aplicación pequeña separa disponibilidad y reserva en servicios que necesitan consultarse constantemente para evitar solapamientos sobre el mismo recurso.
Antes de añadir más coordinación distribuida, conviene revisar si esa decisión debería permanecer junta dentro de un modelo o servicio.
Ambos casos enseñan a buscar una razón concreta de autonomía, no un tamaño mínimo de código.
Para Cursor, Codex o Claude, proporciona requisitos y alternativas permitidas.
Para analizar límites:
Compara mantener este monolito modular con extraer una capacidad. Justifica cada candidato por cohesión, datos, equipo y despliegue. No asignes un microservicio a cada agregado. Distingue evidencia de hipótesis y señala costes nuevos.
Para generar una integración:
Implementa solo el adaptador HTTP de Sales según este contrato de Inventory. Valida datos desconocidos y distingue producto desconocido, disponibilidad cero y fallo técnico. No importes entidades externas ni supongas una transacción compartida. No agregues reintentos de mutaciones sin garantías documentadas.
Para revisar el proceso:
Recorre esta compra con pérdida de respuesta y mensaje duplicado. Identifica estados intermedios, responsables y garantías pendientes. No afirmes que Outbox entrega exactamente una vez ni que una Saga revierte automáticamente efectos remotos.
Una persona debe revisar viabilidad operativa y límites del negocio. Un conjunto de carpetas y Dockerfiles generado por IA no demuestra una arquitectura autónoma.
Payments escribe su tabla, pero Sales la actualiza directamente para resolver incidencias. ¿Qué autonomía se ha comprometido?
Sales no recibe respuesta a una solicitud de pago. ¿Puede iniciar otro intento con una referencia nueva suponiendo que el anterior falló?
Un contexto tiene cinco agregados. El equipo propone cinco microservicios como regla automática. ¿Qué análisis falta?
1. La propiedad de datos y la capacidad de evolucionar reglas y esquema sin consumidores que las eludan. La resolución de incidencias necesita una capacidad autorizada o un procedimiento explícito, no escritura arbitraria entre servicios.
2. No. El cobro puede haberse realizado. Hay que consultar o repetir según el contrato de la misma operación lógica, evitando introducir otro efecto por desconocer el resultado.
3. Cohesión funcional, dependencia de decisiones, propiedad de datos, necesidades de despliegue, equipo y operación. Los agregados pueden orientar candidatos, pero no fijan por sí solos unidades de servicio.
DDD aporta límites y lenguaje para discutir servicios alineados con el negocio. La red, el despliegue y la operación añaden decisiones que esos límites conceptuales no resuelven automáticamente.
Antes de separar, comprueba qué independencia obtendrás, qué datos poseerá cada servicio y cómo reconocerás fallos parciales.
Un monolito modular y una arquitectura de microservicios pueden respetar modelos bien diseñados. La elección debe justificarse por las necesidades del sistema y la capacidad de sostener sus garantías.
Cargando tus opciones de aprendizaje…
Cargando conversación…
Integra la colección construyendo una API de pedidos con TypeScript, Express, Zod y SQLite. Incluye los archivos del proyecto, reglas del dominio, eventos, control de versiones, pruebas con Vitest y comandos para ejecutarla y verificarla localmente.
Aprende a orientar agentes de IA con reglas del negocio, límites de contexto y criterios verificables. Un caso en TypeScript muestra cómo preparar instrucciones, proteger Order, diseñar pruebas y revisar cambios sin delegar el criterio arquitectónico.
Refactoriza la confirmación de pedidos desde un controlador acoplado hacia Order, caso de uso, puerto y adaptadores. Aprende la regla de dependencias, composición manual y pruebas sin infraestructura, con TypeScript y Express.