Czym jest Clean Architecture?

Definicja i podstawowe założenia

Clean Architecture, zaproponowana przez Roberta C. Martina (znanego jako Uncle Bob), to podejście do projektowania oprogramowania, które kładzie nacisk na separację odpowiedzialności i niezależność od frameworków, baz danych czy interfejsów użytkownika. W centrum tego podejścia znajduje się logika biznesowa, która pozostaje odizolowana od szczegółów technicznych.

Warstwy Clean Architecture

Architektura ta opiera się na podziale aplikacji na koncentryczne warstwy:

• Warstwa encji: Zawiera obiekty biznesowe i reguły, które są niezależne od aplikacji.
• Warstwa przypadków użycia: Definiuje logikę aplikacji i operacje biznesowe.
• Warstwa interfejsów: Adaptuje dane między warstwą przypadków użycia a zewnętrznymi elementami.
• Warstwa frameworków i sterowników: Zawiera wszystkie szczegóły techniczne, takie jak bazy danych, frameworki czy interfejsy użytkownika.

źródło: blog.cleancoder.com

Zasada zależności

Kluczową zasadą Clean Architecture jest reguła zależności, która mówi, że zależności między warstwami mogą iść tylko w jednym kierunku – do środka. Oznacza to, że warstwy wewnętrzne nie wiedzą nic o warstwach zewnętrznych, co zapewnia ich niezależność i łatwość testowania.

Kiedy warto stosować Clean Architecture?

Złożone projekty z długim cyklem życia

Clean Architecture jest szczególnie przydatna w projektach, które:

• Będą rozwijane przez długi czas: Gdy aplikacja ma służyć przez wiele lat i być regularnie rozwijana.
• Mają złożone reguły biznesowe: Gdy logika biznesowa jest skomplikowana i wymaga jasnego oddzielenia od szczegółów technicznych.
• Wymagają elastyczności technologicznej: Gdy istnieje prawdopodobieństwo zmiany technologii, frameworków czy baz danych w przyszłości.

Projekty wymagające wysokiej testowalności

• Automatyzacja testów: Clean Architecture ułatwia pisanie testów jednostkowych dzięki izolacji logiki biznesowej.
• Niezależność od infrastruktury: Możliwość testowania logiki biznesowej bez konieczności uruchamiania baz danych czy zewnętrznych serwisów.
• Łatwiejsze mockowanie: Dzięki jasno zdefiniowanym interfejsom między warstwami, mockowanie zależności staje się prostsze.

Praktyczne aspekty implementacji Clean Architecture

Zalety Clean Architecture

• Niezależność od frameworków: Logika biznesowa nie jest uzależniona od konkretnych technologii.
• Testowalność: Łatwiejsze pisanie testów jednostkowych dla logiki biznesowej.
• Łatwość utrzymania: Jasna struktura ułatwia wprowadzanie zmian i rozwój aplikacji.
• Łatwość adaptacji: Możliwość szybkiego dostosowania się do zmieniających się wymagań technologicznych.

Wyzwania związane z Clean Architecture

• Początkowa złożoność: Implementacja Clean Architecture wymaga więcej czasu na początku projektu.
• Większa ilość kodu: Więcej warstw oznacza więcej kodu, co może być wyzwaniem w mniejszych projektach.
• Ścisła dyscyplina: Wymaga konsekwentnego przestrzegania zasad przez cały zespół.

Przykład implementacji Clean Architecture

Struktura projektu

src/
├── domain/              # Warstwa encji
│   ├── entities/
│   └── repositories/    # Interfejsy repozytoriów
├── application/         # Warstwa przypadków użycia
│   ├── usecases/
│   └── services/
├── interfaces/          # Warstwa interfejsów
│   ├── controllers/
│   └── presenters/
└── infrastructure/      # Warstwa frameworków i sterowników
    ├── database/
    ├── external/
    └── web/

Przepływ danych w Clean Architecture

1. Żądanie użytkownika trafia do warstwy frameworków.
2. Kontroler w warstwie interfejsów przetwarza żądanie.
3. Przypadek użycia w warstwie aplikacji implementuje logikę biznesową.
4. Encje w warstwie domeny zawierają reguły biznesowe.
5. Odpowiedź wraca tą samą drogą, ale w przeciwnym kierunku.