SDD en microservicios: ¿cómo gestionar cambios que afectan a varios servicios?

Cuando un cambio en microservicios "derrama" hacia otros servicios y parece que SDD pierde eficiencia, el diagnóstico habitual apunta a la metodología. Casi siempre el diagnóstico correcto apunta a la arquitectura.

SDD funciona con precisión quirúrgica cuando los dominios están bien aislados. Si un cambio de negocio genuinamente pertenece a un solo bounded context, el spec vive en un único repositorio, el agente lo implementa de forma independiente y el deploy no requiere coordinación. Ese es el escenario ideal — y el más frecuente en organizaciones que han invertido en diseño de dominios.

El escenario problemático surge cuando los dominios no están bien definidos: la lógica de negocio está repartida entre dos o más servicios de forma arbitraria, y cualquier cambio significativo requiere tocar múltiples repositorios. En ese caso, el problema es la deuda de diseño, no la metodología.

Tres estrategias para gestionar cambios cross-dominio

Consumer-Driven Contracts en la práctica

Pact IO permite que el consumidor defina sus expectativas de contrato de forma independiente. El proveedor verifica esas expectativas en su propio pipeline de CI, sin necesidad de despliegues coordinados ni entornos de integración compartidos. El spec SDD de cada servicio incluye la referencia al contrato de Pact correspondiente.

// consumer.pact.spec.ts — define lo que el consumidor espera
import { PactV3, MatchersV3 } from '@pact-foundation/pact';

const provider = new PactV3({
  consumer: 'orders-service',
  provider: 'inventory-service',
});

describe('Inventory API — contrato del consumidor', () => {
  it('devuelve stock disponible para un SKU válido', async () => {
    await provider
      .addInteraction({
        states: [{ description: 'el SKU ABC-123 tiene stock' }],
        uponReceiving: 'solicitud de stock para SKU ABC-123',
        withRequest: { method: 'GET', path: '/stock/ABC-123' },
        willRespondWith: {
          status: 200,
          body: MatchersV3.like({ sku: 'ABC-123', available: 42 }),
        },
      })
      .executeTest(async (mockServer) => {
        const result = await checkStock(mockServer.url, 'ABC-123');
        expect(result.available).toBeGreaterThan(0);
      });
  });
});

// El proveedor (inventory-service) verifica este contrato en su CI
// sin necesidad de que los dos equipos sincronicen el deployment

El spec SDD delorders-serviceincluye el contrato Pact como criterio de aceptación. El delinventory-serviceincluye la verificación como parte de su DoD. Cada equipo trabaja de forma independiente.

La regla de oro: DDD antes que SDD

Si cada semana aparecen cambios que afectan a tres o más microservicios, la inversión prioritaria no es mejorar las specs SDD. Es revisar el diseño de dominios. Los síntomas de dominios mal definidos son siempre los mismos: