Czysta architektura — dlaczego naprawdę czyni systemy elastycznymi

Jeśli czytałeś już wprowadzenie do Clean Architecture, znasz cztery warstwy i regułę zależności. Tu pokazujemy dlaczego to konkretnie działa — na przykładzie zmiany, która w typowym kodzie byłaby bolesna, a w czystej architekturze jest niemal niezauważalna.

Test elastyczności: zmiana dostawcy e-maili

Wyobraź sobie, że firma decyduje się przejść z SendGrid na Amazon SES. W wielu systemach to oznacza szukanie po całym kodzie wywołań SendGridClient, rozsianych w kontrolerach, serwisach i logice biznesowej.

// ❌ Logika biznesowa zna konkretnego dostawcę
public class ZamowienieService
{
    public void PotwierdzZamowienie(Zamowienie z)
    {
        var client = new SendGridClient("api-key");
        client.SendEmailAsync(z.KlientEmail, "Potwierdzenie zamówienia");
    }
}

Zmiana dostawcy oznacza edycję ZamowienieService — klasy odpowiedzialnej za reguły biznesowe zamówień, nie za wysyłkę e-maili.

Z regułą zależności: zmiana dostawcy = jedna nowa klasa

public interface IPowiadomienia
{
    Task WyslijAsync(string email, string tresc);
}

public class ZamowienieService
{
    private readonly IPowiadomienia _powiadomienia;
    public ZamowienieService(IPowiadomienia powiadomienia) => _powiadomienia = powiadomienia;

    public async Task PotwierdzZamowienie(Zamowienie z)
    {
        await _powiadomienia.WyslijAsync(z.KlientEmail, "Potwierdzenie zamówienia");
    }
}

public class SesPowiadomienia : IPowiadomienia
{
    public Task WyslijAsync(string email, string tresc) { return Task.CompletedTask; }
}

Migracja na Amazon SES to nowa klasa SesPowiadomienia i jedna linijka w konfiguracji DI. ZamowienieService — serce logiki biznesowej — nie zmienia się w ogóle. To dokładnie ten sam mechanizm co Open/Closed Principle.

Elastyczność ma cenę — nie jest darmowa

Jeśli w całej historii projektu dostawca e-maili nigdy się nie zmienił i nigdy się nie zmieni, taka abstrakcja to niepotrzebny koszt — YAGNI ostrzega dokładnie przed tym. Elastyczność wprowadzasz świadomie, tam gdzie realnie przewidujesz zmienność.

Jak to rozpoznać w istniejącym kodzie

Sygnał ostrzegawczy: klasa z logiką biznesową, która bezpośrednio odwołuje się do konkretnej biblioteki zamiast do interfejsu. Test w jedno pytanie: czy mogę przetestować tę logikę bez uruchamiania prawdziwej bazy danych, prawdziwego serwera SMTP czy prawdziwego zewnętrznego API? Jeśli nie — logika biznesowa i szczegóły techniczne są splątane.

Podsumowanie

Elastyczność w czystej architekturze bierze się z tego, że logika biznesowa zależy od abstrakcji, nie od konkretnych implementacji technicznych. Cena tej elastyczności to dodatkowa warstwa abstrakcji — wprowadzaj ją tam, gdzie zmienność jest realna, nie wszędzie z automatu.