Architektura Clean/Onion/Hexagonal/Ports&Adapters

Aktualizacja 24.03.2020

Dodałem podział na porty wewnętrzne i zewnętrzne. Zaktualizowałem heksagonalny wykres zależności.

Spotkałem już kilka nazw, a każda z nich wskazywała na tę samą architekturę. Różniły się one co prawda tym, jak był rysowany wykres zależności, ale idea była taka sama.

Ogólnie mówiąc, ta architektura wydaje się czymś naturalnym, a mimo wszystko jest wciąż dość rzadko spotykana. Czym się wyróżnia? Tak w skrócie, to w tej architekturze najważniejsza jest logika biznesowa, tzw. „Core” aplikacji. Jest tam zdefiniowane wszystko to, co jest niezbędne dla działania. Wszystko inne jest implementowane w oddzielnych projektach/warstwach, które mają zależność do „Core”.

Przykład

Aby łatwiej to zrozumieć, posłużmy się prostym przykładem – aplikacja potrzebuje gdzieś przechowywać dane. Z punktu widzenia logiki biznesowej nie ma różnicy, czy to będzie plik tekstowy, baza SQL, czy baza NoSQL. Zatem warstwa logiki biznesowej („Core”) definiuje interfejs, w którym zawiera jakie operacje będą jej niezbędne, a inna warstwa (np. dostępu do danych) implementuje ten interfejs. W takiej implementacji wykorzystuje to, co jest jej potrzebne, np. łączy się z bazą SQL z wykorzystaniem EF. Jednakże to wszystko jest w osobnym projekcie, „Core” nic o tym nie wie. Ponadto główne modele również są zdefiniowane w warstwie logiki biznesowej – jeśli warstwa dostępu do danych potrzebuje trochę innych modeli, to tworzy własne i dodaje mapowanie jednych na drugie.

W praktyce może to wyglądać następująco:

Mamy projekt „Core”, w którym jest zdefiniowana cała nasza logika biznesowa (w tym przypadku w folderze „Services”). Są tam też umieszczone wszystkie modele, które ta logika wykorzystuje (w tym przypadku w folderze „Models”). Dodatkowo mamy zdefiniowane wszystkie interfejsy, których implementacja jest niezbędna do działania logiki biznesowej (w tym przypadku w folderze „Interfaces”).
Do tego mamy projekt „DAL”, który zależy od projektu „Core”. W tym projekcie łączymy się z bazą danych z wykorzystaniem EF – tylko ten projekt ma zależności do EF, „Core” nie ma żadnych zależności.

Uproszczony opis

Nasze projekty możemy podzielić na 3 kategorie:

• Core
• Infrastruktura
• Prezentacja

W „Core” powinien znajdować się tylko projekt (lub projekty) posiadający logikę biznesową. Do „prezentacji” należą wszystkie projekty, które są odpowiedzialne za zwracanie danych z naszego systemu (np. aplikacja WebApi lub MVC). W „infrastrukturze” znajdują się wszystkie pozostałe projekty. To tutaj znajdują się implementacje wszystkich interfejsów zdefiniowanych w kategorii „Core”. Całość może wyglądać tak:

Każdy interfejs publiczny zdefiniowany w Core jest pewnego rodzaju portem. Może być on portem wewnętrznym lub zewnętrznym – w zależności od tego, gdzie jest używany.
Porty wewnętrzne to wszystkie te, z których korzysta infrastruktura. Ich implementacja znajduje się na zewnątrz Core (w Infrastrukturze), a ich użycie znajduje się wewnątrz Core.
Porty zewnętrzne są zdefiniowane w Core. Ich implementacja znajduje się również wewnątrz Core, ale ich użycie znajduje się na zewnątrz Core (w warstwie Prezentacji).

Wykres zależności

Dla takiej aplikacji wykres zależności może wyglądać następująco:

Można go też zaprezentować tak:

W obu jednak przypadkach zależności nie idą od góry do dołu, tylko od zewnątrz do wewnątrz.

Ale po co to wszystko?

Jaki jest w ogóle sens stosowania takiej architektury? Co jest nie tak w najbardziej popularnej, n-warstwowej architekturze, w której to z reguły baza danych jest na samym dole/w centrum?

Bardzo często jest tak, że na początku nasza aplikacja jest prosta. Robi ona niewiele – dane z formularza są zapisywane do bazy danych. Taki typowy CRUD. Wtedy taka n-warstwowa architektura jest jak najbardziej ok. Wtedy to „n” z reguły wynosi 3 – Api (kontrolery), logika biznesowa (serwisy), baza danych (repozytoria). W takich projektach logika biznesowa praktycznie nie istnieje – kontrolery są jednolinijkowe i wywołuje się w nich serwisy. Serwisy są jednolinijkowe i wywołuje się w nich repozytoria. Repozytoria są jednolinijkowe i wywołuje się w nich podstawowe zapytania SQL (z reguły z użyciem ORM).

Niestety, wszystko co dobre szybko się kończy. Biznes zaczyna oczekiwać, aby nasza aplikacja robiła coraz więcej. Do naszego systemu zaczynają dochodzić walidacje – najpierw proste, potem coraz bardziej skomplikowane. Dodatkowo okazuje się, że podczas dodawania czegoś do bazy, musimy wysłać e-mail lub sms. Ponadto potrzebujemy połączyć się z jakąś inną aplikacją, wysłać jej żądanie, a potem odpowiednio je przetworzyć. Wszystko to powoduje, że nasza aplikacja się rozrasta, a logika biznesowa zaczyna komplikować.

W takich sytuacjach dzieją się z reguły dwie rzeczy – albo liczba warstw z „3” zaczyna rosnąć dość mocno, albo nasz kod biznesowy zaczyna być upychany we wszystkich warstwach. Bardzo często wtedy to logika biznesowa pojawia się już nie tylko w serwisach, ale również w kontrolerach i w repozytoriach. Nasza aplikacja coraz bardziej puchnie i coraz trudniej jest nam nad tym wszystkim zapanować. Nie mówiąc już o sytuacjach, w których klient zaczyna nam specyfikować funkcjonalności zaczynając od bazy danych, bo to ona, z punktu widzenia naszej architektury, wydaje się najważniejsza.

Aby do tego wszystkiego nie dopuścić, najlepiej jest od razu założyć, że to logika biznesowa jest w centrum. Że to ona jest najważniejsza. Że to od niej wszystko się zaczyna. Że modele danych służą logice biznesowej, a nie bazie danych. Że jeśli warstwa prezentacji potrzebuje wyświetlić dane z kilku modeli albo ograniczony zbiór danych z jednego modelu, to może nasze obecne modele nie do końca odpowiadają potrzebom biznesowym i powinniśmy je rozbudować lub zmienić.

Dzięki takiemu podejściu, warstwy mniej ważne muszą dostosowywać się do naszej logiki biznesowej (a nie nasza logika biznesowa do tych warstw). Co to oznacza? Często jest tak, że interfejsy mówią pojęciami charakterystycznymi dla danej warstwy. Jeśli zdefiniujemy je w warstwach mniej ważnych, to może okazać się, że będą miały operacje niezrozumiałe (lub nawet niepotrzebne) z punktu widzenia logiki biznesowej. Jeśli natomiast stworzymy je tam, gdzie faktycznie są wykorzystywane (czyli w warstwie logiki biznesowej), to łatwiej będzie nam sprecyzować w nich takie operacje, które będą miały znaczenie z punktu widzenia logiki biznesowej (szczegóły ich implementacji będą ukryte w warstwach zależnych). Dodatkowo te operacje będą współgrały z najważniejszymi elementami naszej aplikacji.

Ponadto taka architektura daje nam dość dużo korzyści. Pisanie testów staje się łatwiejsze, ponieważ cała logika jest zdefiniowana w jednym miejscu. Osobno możemy przetestować logikę biznesową, a osobno „adaptery”, czyli implementacje interfejsów zdefiniowanych w „Core”. Dzięki temu nasze testy będą bardziej granularne i łatwiejsze w utrzymaniu. Aplikacja rośnie nam wszerz, a nie wzdłuż. Staje się ona wygodna w rozszerzaniu, ponieważ mamy stały schemat działania – dodajemy interfejs w „Core”, a jego implementację w osobnym projekcie. Wiadomo gdzie co jest i łatwiej jest taki projekt utrzymać.

Dzięki temu nie ma już problemów związanych z tym, gdzie należy umieścić kolejną funkcjonalność – albo robimy to bezpośrednio w „Core”, albo dodajemy interfejs, który dostarcza wymaganą funkcjonalność, a jego implementację umieszczamy w osobnym projekcie. Skąd mamy wiedzieć, który kod umieścić w którym projekcie? Na początku proponuję cały kod, który nie wymaga zewnętrznych zależności trzymać w „Core”, a wszystko to, co wymaga dostępu do jakiś innych bibliotek (np. EF czy inny ORM, HttpClient, FluentValidation) trzymać w osobnych projektach. Niech nasz „Core” na początku będzie bez żadnych zależności. Z czasem nauczymy się, które zależności są „ok”, a które powinniśmy umieścić w osobnym projekcie.