Ludo Programming

După ce o arhitectură CQRS este stabilă, următorul pas natural este rafinarea ei prin extensii și pattern-uri care o fac mai robustă, mai testabilă și mai ușor de întreținut. În această etapă, ne concentrăm pe trei direcții-cheie: decoratori peste MediatR, event publishing și audit logging. Toate acestea adresează nevoi comune ale aplicațiilor enterprise, fără să compromită separarea clară dintre comenzi și interogări.

🎯 1. Decorators peste MediatR pentru Logging, Retry și Validation

Unul dintre cele mai elegante moduri de a introduce comportamente comune în pipeline-ul aplicației este prin decoratori. În ecosistemul MediatR, acest lucru se realizează prin implementarea interfeței IPipelineBehavior<TRequest, TResponse>.

Această interfață acționează ca un middleware care interceptează toate cererile trimise către MediatR, permițând adăugarea logicilor cross-cutting – adică funcționalități care traversează mai multe componente, precum:

• Logging – urmărirea cererilor și răspunsurilor pentru depanare și monitorizare;

• Retry – reexecutarea unei comenzi în caz de erori tranzitorii;

• Validation – validarea cererilor înainte de procesare.

Exemplu simplu de decorator pentru logging:

public class LoggingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    private readonly ILogger<LoggingBehavior<TRequest, TResponse>> _logger;

    public LoggingBehavior(ILogger<LoggingBehavior<TRequest, TResponse>> logger)
        => _logger = logger;

    public async Task<TResponse> Handle(
        TRequest request, 
        RequestHandlerDelegate<TResponse> next, 
        CancellationToken cancellationToken)
    {
        _logger.LogInformation("Handling {Request}", typeof(TRequest).Name);
        var response = await next();
        _logger.LogInformation("Handled {Request}", typeof(TRequest).Name);
        return response;
    }
}

Această abordare permite adăugarea de comportamente fără a „polua” handler-ele individuale. Cu un simplu services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));, toate comenzile și interogările beneficiază automat de logging centralizat.

📢 2. Event Publishing: Domain Events vs Integration Events

Evenimentele sunt o componentă naturală a modelului Domain-Driven Design, iar în contextul CQRS, ele capătă un rol major. În esență, vorbim despre două categorii:

• Domain Events – reprezintă ceva ce s-a întâmplat în interiorul domeniului. De exemplu, PostCreatedDomainEvent poate fi declanșat atunci când o postare nouă este creată.

• Integration Events – sunt utilizate pentru a notifica alte sisteme externe sau microservicii despre o schimbare. Ele traversează limitele aplicației.

Pentru Domain Events, MediatR oferă o integrare elegantă prin interfața INotification și handler-ele asociate INotificationHandler<TNotification>.

public class PostCreatedDomainEvent : INotification
{
    public Guid PostId { get; }
    public string Title { get; }

    public PostCreatedDomainEvent(Guid postId, string title)
    {
        PostId = postId;
        Title = title;
    }
}

public class PostCreatedEventHandler : INotificationHandler<PostCreatedDomainEvent>
{
    private readonly ILogger<PostCreatedEventHandler> _logger;
    public PostCreatedEventHandler(ILogger<PostCreatedEventHandler> logger) => _logger = logger;

    public Task Handle(PostCreatedDomainEvent notification, CancellationToken cancellationToken)
    {
        _logger.LogInformation("New post created: {Title}", notification.Title);
        return Task.CompletedTask;
    }
}

Astfel, domeniul rămâne coerent, iar logica de reacție la evenimente poate fi extinsă fără a afecta nucleul aplicației.

Pentru Integration Events, este recomandată o abordare asincronă – de exemplu, publicarea în RabbitMQ, Azure Service Bus sau Kafka – pentru a decupla complet comunicația între aplicații.

🧾 3. Audit Logging la comenzi

În multe aplicații enterprise, urmărirea acțiunilor utilizatorilor este o cerință obligatorie, mai ales în medii financiare, medicale sau guvernamentale. În CQRS, audit logging-ul poate fi implementat elegant tot printr-un pipeline behavior sau direct în handler-ele de comandă.

O abordare simplă presupune crearea unei entități AuditLog și salvarea evenimentelor într-o tabelă auxiliară sau într-un Event Store dedicat.

public class AuditBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    private readonly IAuditService _auditService;

    public AuditBehavior(IAuditService auditService)
        => _auditService = auditService;

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        var response = await next();
        await _auditService.SaveAsync(request, response);
        return response;
    }
}

Prin această metodă, fiecare comandă trimisă prin MediatR lasă o urmă în baza de date – cu detalii despre cine a făcut acțiunea, când și ce s-a modificat.

Această transparență ajută la depanare, securitate și conformitate cu standarde precum GDPR sau ISO 27001.

🔚 Concluzie

Extensiile și pattern-urile din această etapă duc arhitectura CQRS la un nivel matur.

Prin decoratori, evenimente și audit logging, aplicația devine:

• Scalabilă – logica comună este centralizată;

• Observabilă – toate acțiunile pot fi urmărite și analizate;

• Ușor de extins – adăugarea unui nou comportament global nu afectează handler-ele existente.

CQRS nu înseamnă doar separarea dintre comenzi și interogări, ci și crearea unui cadru solid care facilitează mentenanța, auditul și extensibilitatea pe termen lung.