Arquitectura & sistemas18 de marzo de 202627 min de lectura

El Patrón Estrategia en Microservicios de Procesamiento

Arquitectura para lectura automatizada de facturas y documentos: Strategy Pattern en C# para soportar múltiples formatos sin un monolito de if-else, con espacio para crecer.

Los servicios que leen documentos en producción enfrentan una realidad incómoda: los formatos multiplican. Hoy PDF escaneado, mañana XML de factura electrónica, pasado mañana una imagen con ruido. Si el núcleo del sistema está lleno de if (tipo == …), cada formato nuevo vuelve más frágil todo el servicio. El Strategy Pattern ofrece una salida clásica y efectiva: aislar variaciones en estrategias intercambiables detrás de una interfaz estable.

En este artículo me centro en C# / .NET y un microservicio de procesamiento, pero la idea trasciende el lenguaje: el dominio habla de “documento entendido”, no de “bytes de PDF”.

If-else monolítico vs estrategias inyectables

Contrato estable, variaciones encapsuladas

El servicio orquesta: recibe un documento, detecta o recibe el tipo, delega a la estrategia adecuada y unifica el resultado hacia el resto del sistema (validación de negocio, antifraud, almacenamiento). La clave es que el modelo de salida sea compartido aunque las entradas difieran.

public interface IDocumentoParser
{
    bool PuedeProcesar(DocumentoEntrada entrada);
    Task<ResultadoParseo> ParsearAsync(DocumentoEntrada entrada, CancellationToken ct);
}

public sealed class OrquestadorDocumentos
{
    private readonly IEnumerable<IDocumentoParser> _parsers;

    public OrquestadorDocumentos(IEnumerable<IDocumentoParser> parsers) => _parsers = parsers;

    public async Task<ResultadoParseo> ProcesarAsync(DocumentoEntrada entrada, CancellationToken ct)
    {
        var parser = _parsers.FirstOrDefault(p => p.PuedeProcesar(entrada))
            ?? throw new FormatoNoSoportadoException(entrada.MimeType);
        return await parser.ParsearAsync(entrada, ct);
    }
}

Registro en DI (ASP.NET Core)

// Program.cs / extensiones
builder.Services.AddSingleton<IDocumentoParser, PdfFacturaParser>();
builder.Services.AddSingleton<IDocumentoParser, XmlDgtParser>();
builder.Services.AddSingleton<IDocumentoParser, ImagenHeuristicaParser>();
builder.Services.AddSingleton<OrquestadorDocumentos>();

Cada parser evoluciona a su ritmo: equipos distintos pueden publicar versiones si el empaquetado lo permite.

Escalar “orgánicamente” sin reescribir el núcleo

Cuando aparece un nuevo formato, añades una clase, tests y registro — el orquestador permanece delgado. Eso reduce el riesgo de regresiones en flujos ya estables y mejora el SEO interno del repositorio: los nuevos desarrolladores encuentran el patrón repetible en lugar de cazar condiciones esparcidas por mil líneas.

En microservicios, combina esto con límites claros: un servicio demasiado grande deja de ser “micro”, pero un núcleo bien diseñado permite extraer pipelines (OCR, normalización, NLP) sin reventar el contrato público.

Observabilidad: mismo patrón, mismas métricas

Etiqueta spans por tipo de documento y por parser. Cuando un formato falla más que otros, los datos te dirigen a la estrategia correcta — no a adivinar en producción.

Pruebas: tabla de casos por formato

Crea una matriz de pruebas donde cada fila sea un documento representativo (factura XML válida, PDF escaneado borroso, imagen rotada) y cada columna sea el resultado esperado en el modelo de dominio. Cuando un nuevo país o proveedor agrega variaciones, añades filas — no reescribes el orquestador. Esta disciplina es la que permite dormir cuando el pipeline corre a las 3 a.m.

En cuanto a rendimiento, perfila el costo de CPU/memoria por estrategia: un parser de imagen pesada no debería bloquear colas rápidas de XML. Patrones como colas separadas, batching o workers especializados pueden convivir con Strategy si el contrato de entrada/salida permanece estable.

Etiquetas:#C##microservicios#patrones de diseño#OCR