Clean Architecture to podejście architektoniczne, które zyskuje coraz większą popularność w świecie .NET. W tym artykule pokażę, jak praktycznie wdrożyć te zasady w projekcie bankowym.
Clean Architecture opiera się na kilku fundamentalnych zasadach:
MediatR świetnie wspiera implementację Clean Architecture poprzez wzorzec mediator:
public class CreateAccountCommand : IRequest<AccountDto>
{
public string AccountNumber { get; set; }
public decimal InitialBalance { get; set; }
}
public class CreateAccountHandler : IRequestHandler<CreateAccountCommand, AccountDto>
{
private readonly IAccountRepository _repository;
public CreateAccountHandler(IAccountRepository repository)
{
_repository = repository;
}
public async Task<AccountDto> Handle(CreateAccountCommand request,
CancellationToken cancellationToken)
{
// Logika biznesowa
var account = Account.Create(request.AccountNumber, request.InitialBalance);
await _repository.AddAsync(account);
return AccountDto.FromEntity(account);
}
}
Jedną z największych zalet MediatR są pipeline behaviors, które pozwalają na eleganckie dodawanie cross-cutting concerns:
public class ValidationBehavior<TRequest, TResponse>
: IPipelineBehavior<TRequest, TResponse>
{
private readonly IEnumerable<IValidator<TRequest>> _validators;
public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
{
_validators = validators;
}
public async Task<TResponse> Handle(TRequest request,
RequestHandlerDelegate<TResponse> next,
CancellationToken cancellationToken)
{
var context = new ValidationContext<TRequest>(request);
var failures = _validators
.Select(v => v.Validate(context))
.SelectMany(result => result.Errors)
.Where(f => f != null)
.ToList();
if (failures.Any())
{
throw new ValidationException(failures);
}
return await next();
}
}
W regulowanym środowisku bankowym Clean Architecture przynosi szczególne korzyści:
Clean Architecture z MediatR to potężna kombinacja dla projektów .NET, szczególnie w środowiskach regulowanych. Wymaga pewnej początkowej inwestycji w strukturę projektu, ale zwraca się szybko poprzez łatwiejsze utrzymanie i rozbudowę systemu.
W kolejnych artykułach pokażę bardziej zaawansowane wzorce i techniki implementacji.
]]>Pipeline Behaviors w MediatR to mechanizm pozwalający na przechwytywanie i modyfikowanie przetwarzania żądań (requestów) przed wykonaniem właściwego handlera oraz po jego zakończeniu. Koncepcyjnie przypominają middleware w ASP.NET Core, z tą różnicą, że działają na poziomie logiki biznesowej, a nie warstwy HTTP.
Każdy behavior implementuje interfejs IPipelineBehavior<TRequest, TResponse> i otrzymuje:
TRequest)next do wywołania kolejnego elementu w łańcuchuDzięki temu behaviors tworzą łańcuch odpowiedzialności (Chain of Responsibility pattern), przez który przechodzi każde żądanie.
W aplikacjach biznesowych nieuchronnie pojawiają się zagadnienia przekrojowe (cross-cutting concerns) – aspekty funkcjonalności, które przewijają się przez wiele komponentów systemu:
Tradycyjne podejścia do rozwiązania tych problemów prowadzą do:
Pipeline behaviors rozwiązują te problemy poprzez wydzielenie zagadnień przekrojowych do osobnych, reużywalnych komponentów.
public class ValidationBehavior<TRequest, TResponse>
: IPipelineBehavior<TRequest, TResponse>
where TRequest : IRequest<TResponse>
{
private readonly IEnumerable<IValidator<TRequest>> _validators;
private readonly ILogger<ValidationBehavior<TRequest, TResponse>> _logger;
public ValidationBehavior(
IEnumerable<IValidator<TRequest>> validators,
ILogger<ValidationBehavior<TRequest, TResponse>> logger)
{
_validators = validators;
_logger = logger;
}
public async Task<TResponse> Handle(
TRequest request,
RequestHandlerDelegate<TResponse> next,
CancellationToken cancellationToken)
{
var requestName = typeof(TRequest).Name;
// Jeśli brak walidatorów, pomijamy walidację
if (!_validators.Any())
{
_logger.LogDebug(
"Brak walidatorów dla {RequestName}, pomijam walidację",
requestName);
return await next();
}
_logger.LogDebug(
"Walidacja {RequestName} przy użyciu {ValidatorCount} walidatorów",
requestName,
_validators.Count());
// Tworzymy kontekst walidacji
var context = new ValidationContext<TRequest>(request);
// Wykonujemy wszystkie walidatory równolegle
var validationResults = await Task.WhenAll(
_validators.Select(v => v.ValidateAsync(context, cancellationToken))
);
// Zbieramy wszystkie błędy walidacji
var failures = validationResults
.SelectMany(result => result.Errors)
.Where(failure => failure != null)
.ToList();
if (failures.Any())
{
_logger.LogWarning(
"Walidacja {RequestName} zakończona niepowodzeniem. Liczba błędów: {ErrorCount}",
requestName,
failures.Count);
throw new ValidationException(failures);
}
_logger.LogDebug("Walidacja {RequestName} zakończona sukcesem", requestName);
// Przechodzimy dalej w łańcuchu
return await next();
}
}
Kluczowe aspekty implementacji:
Task.WhenAll pozwala na równoczesne uruchomienie wszystkich walidatorów, co poprawia wydajnośćservices.AddMediatR(cfg =>
{
cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly());
// Behaviors wykonują się w kolejności rejestracji
cfg.AddBehavior(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));
cfg.AddBehavior(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));
cfg.AddBehavior(typeof(IPipelineBehavior<,>), typeof(AuthorizationBehavior<,>));
cfg.AddBehavior(typeof(IPipelineBehavior<,>), typeof(TransactionBehavior<,>));
cfg.AddBehavior(typeof(IPipelineBehavior<,>), typeof(PerformanceBehavior<,>));
});
// Rejestracja walidatorów FluentValidation
services.AddValidatorsFromAssembly(Assembly.GetExecutingAssembly());
Uwagi dotyczące kolejności:
Pipeline behaviors tworzą strukturę przypominającą “matriószkę” – każdy behavior otacza kolejny:
Żądanie (Request)
│
├─→ LoggingBehavior START
│ │
│ ├─→ ValidationBehavior START
│ │ │
│ │ ├─→ AuthorizationBehavior START
│ │ │ │
│ │ │ ├─→ TransactionBehavior START
│ │ │ │ │
│ │ │ │ ├─→ HANDLER
│ │ │ │ │
│ │ │ │ └─← TransactionBehavior END (commit)
│ │ │ │
│ │ │ └─← AuthorizationBehavior END
│ │ │
│ │ └─← ValidationBehavior END
│ │
│ └─← LoggingBehavior END
│
└─← Odpowiedź (Response)
Istotne konsekwencje:
public class TransactionBehavior<TRequest, TResponse>
: IPipelineBehavior<TRequest, TResponse>
where TRequest : IRequest<TResponse>
{
private readonly IDbContext _context;
private readonly ILogger<TransactionBehavior<TRequest, TResponse>> _logger;
public TransactionBehavior(
IDbContext context,
ILogger<TransactionBehavior<TRequest, TResponse>> logger)
{
_context = context;
_logger = logger;
}
public async Task<TResponse> Handle(
TRequest request,
RequestHandlerDelegate<TResponse> next,
CancellationToken cancellationToken)
{
var requestName = typeof(TRequest).Name;
// Tylko komendy wymagają transakcji
// Zapytania (queries) są read-only i nie modyfikują stanu
if (request is IQuery<TResponse>)
{
return await next();
}
_logger.LogDebug("Rozpoczynam transakcję dla {RequestName}", requestName);
// Rozpoczynamy transakcję z odpowiednim poziomem izolacji
await using var transaction = await _context.BeginTransactionAsync(
IsolationLevel.ReadCommitted,
cancellationToken);
try
{
var response = await next();
await transaction.CommitAsync(cancellationToken);
_logger.LogDebug(
"Transakcja dla {RequestName} zakończona sukcesem",
requestName);
return response;
}
catch (Exception ex)
{
_logger.LogError(
ex,
"Transakcja dla {RequestName} wycofana z powodu błędu",
requestName);
await transaction.RollbackAsync(cancellationToken);
throw;
}
}
}
Kluczowe decyzje projektowe:
ReadCommitted to rozsądny domyślny wybór w większości scenariuszypublic interface ICommand : IRequest<Result> { }
public interface ICommand<TResponse> : IRequest<Result<TResponse>> { }
public interface IQuery<TResponse> : IRequest<Result<TResponse>> { }
public async Task<TResponse> Handle(...)
{
if (request is ICommand || request is ICommand<TResponse>)
{
// Logika specyficzna dla komend
// np. walidacja biznesowa, audyt, transakcje
}
if (request is IQuery<TResponse>)
{
// Logika specyficzna dla zapytań
// np. cache, read-only connection
}
return await next();
}
[AttributeUsage(AttributeTargets.Class)]
public class SkipTransactionAttribute : Attribute { }
public async Task<TResponse> Handle(...)
{
if (request.GetType().GetCustomAttribute<SkipTransactionAttribute>() != null)
{
return await next();
}
// Normalna logika transakcji
}
public class PerformanceBehavior<TRequest, TResponse>
: IPipelineBehavior<TRequest, TResponse>
where TRequest : IRequest<TResponse>
{
private readonly ILogger<PerformanceBehavior<TRequest, TResponse>> _logger;
private readonly IMetrics _metrics;
private const int PerformanceThresholdMs = 500;
public PerformanceBehavior(
ILogger<PerformanceBehavior<TRequest, TResponse>> logger,
IMetrics metrics)
{
_logger = logger;
_metrics = metrics;
}
public async Task<TResponse> Handle(
TRequest request,
RequestHandlerDelegate<TResponse> next,
CancellationToken cancellationToken)
{
var requestName = typeof(TRequest).Name;
var stopwatch = Stopwatch.StartNew();
try
{
var response = await next();
stopwatch.Stop();
var elapsedMs = stopwatch.ElapsedMilliseconds;
// Metryki dla systemu monitoringu
_metrics.RecordRequestDuration(requestName, elapsedMs);
if (elapsedMs > PerformanceThresholdMs)
{
_logger.LogWarning(
"Wydajność: {RequestName} wykonał się w {ElapsedMs}ms (próg: {ThresholdMs}ms). Żądanie: {@Request}",
requestName,
elapsedMs,
PerformanceThresholdMs,
request);
}
else
{
_logger.LogDebug(
"Wydajność: {RequestName} wykonał się w {ElapsedMs}ms",
requestName,
elapsedMs);
}
return response;
}
catch (Exception)
{
stopwatch.Stop();
_metrics.RecordRequestDuration(requestName, stopwatch.ElapsedMilliseconds);
throw;
}
}
}
W systemach bankowych pipeline behaviors przynoszą wymierne korzyści:
public class AuditBehavior<TRequest, TResponse>
: IPipelineBehavior<TRequest, TResponse>
{
// Centralne logowanie wszystkich operacji zgodnie z wymogami PSD2/RODO
// - Kto wykonał operację (użytkownik, system)
// - Kiedy (timestamp z timezone)
// - Co zostało zmienione (przed/po)
// - Kontekst biznesowy (numer konta, kwota)
}
public class AuthorizationBehavior<TRequest, TResponse>
: IPipelineBehavior<TRequest, TResponse>
{
// - Weryfikacja tożsamości (authentication)
// - Kontrola uprawnień (authorization)
// - Sprawdzenie limitów operacyjnych
// - Wykrywanie podejrzanych wzorców
}
[Fact]
public async Task ValidationBehavior_Should_Reject_Invalid_Transfer()
{
// Testowanie behaviora w izolacji, bez konieczności
// uruchamiania całego handlera czy bazy danych
var validators = new[] { new TransferCommandValidator() };
var behavior = new ValidationBehavior<TransferCommand, Result>(validators);
var invalidCommand = new TransferCommand
{
Amount = -100 // Niepoprawna kwota
};
await Assert.ThrowsAsync<ValidationException>(
() => behavior.Handle(invalidCommand, () => Task.FromResult(Result.Success()), default)
);
}
┌─────────────────────────────────────┐
│ Warstwa prezentacji (API) │ ← Deserializacja, routing
├─────────────────────────────────────┤
│ Pipeline Behaviors │ ← Cross-cutting concerns
├─────────────────────────────────────┤
│ Handlery (logika biznesowa) │ ← Czysta logika domeny
├─────────────────────────────────────┤
│ Warstwa dostępu do danych │ ← Persystencja
└─────────────────────────────────────┘
Każda warstwa ma jasno określoną odpowiedzialność. Handlery zawierają tylko logikę biznesową, bez “szumu” infrastrukturalnego.
❌ Źle: Transakcja przed walidacją
cfg.AddBehavior<TransactionBehavior<,>>(); // Otwiera transakcję
cfg.AddBehavior<ValidationBehavior<,>>(); // Może odrzucić żądanie
// Transakcja była otwarta niepotrzebnie!
✅ Dobrze: Walidacja przed transakcją
cfg.AddBehavior<ValidationBehavior<,>>(); // Najpierw sprawdź
cfg.AddBehavior<TransactionBehavior<,>>(); // Potem otwieraj zasoby
❌ Źle: Behavior zawiera logikę biznesową
// To NIE jest zagadnienie przekrojowe, to logika biznesowa!
if (request is TransferCommand transfer && transfer.Amount > 10000)
{
await _fraudDetection.CheckHighValueTransfer(transfer);
}
✅ Dobrze: Behavior wywołuje odpowiednią usługę
// Behavior tylko orkiestruje, logikę zostawia dla serwisów
if (request is IRequiresFraudCheck)
{
await _fraudDetection.CheckRequest(request);
}
Behaviors wykonują się dla każdego żądania. Unikaj:
Każdy behavior to niezależny komponent z jasną odpowiedzialnością – powinien mieć własne testy jednostkowe.
Pipeline Behaviors to fundamentalny element architektury opartej na MediatR. Umożliwiają:
W aplikacjach enterprise, szczególnie w sektorze finansowym, gdzie wymagania dotyczące audytowalności, bezpieczeństwa i spójności są kluczowe, pipeline behaviors stanowią nie tyle opcję, co konieczność architektury.
W następnym artykule przedstawię zaawansowane wzorce łączące pipeline behaviors z result pattern oraz strategię obsługi błędów w systemach rozproszonych.