Event Sourcing

Persiste el estado como una secuencia inmutable de eventos en lugar del estado actual.

Contexto

Auditoría completa, replay de bugs en producción, modelos de lectura derivados, sistemas regulados (banca).

Problema

Guardar solo el estado actual pierde el por qué del cambio.

Solución

Cada cambio es un evento (OrderPlaced, OrderPaid). El estado se reconstruye plegando los eventos.

#Ejemplo en C#

public abstract record DomainEvent(DateTime At);
public record OrderPlaced(Guid Id, decimal Total, DateTime At) : DomainEvent(At);
public record OrderPaid(Guid Id, DateTime At) : DomainEvent(At);

public class Order
{
    public Guid Id { get; private set; }
    public decimal Total { get; private set; }
    public bool Paid { get; private set; }

    public static Order Replay(IEnumerable<DomainEvent> events)
    {
        var order = new Order();
        foreach (var e in events) order.Apply(e);
        return order;
    }

    private void Apply(DomainEvent e)
    {
        switch (e)
        {
            case OrderPlaced p: Id = p.Id; Total = p.Total; break;
            case OrderPaid:     Paid = true; break;
        }
    }
}

Cuándo NO aplicarlo

Si no necesitas auditoría profunda ni replay: añade complejidad enorme.
Si la migración de esquemas de eventos no se planifica: te ahogas.

Tradeoffs

Pro	Contra
Auditoría perfecta + replay	Migración de eventos versionados es difícil
Encaja con CQRS y proyecciones	Snapshots necesarios para entidades con muchos eventos

#extra #events #audit