Nie da się nie zauważyć rosnącego trendu, w którym coraz więcej pasjonatów technologii omawia Architekturę Hexagonalną. Osobiście przyznam, że to termin, który jeszcze niedawno był mi zupełnie obcy. Kiedy zaczynałem podpytywać swoich kolegów z pracy na ten temat, niestety nie zdołali mi dostarczyć jednoznacznej odpowiedzi. Jednak, jak to często bywa, zacząłem zgłębiać temat i odkryłem w nim fascynujący świat architektury hexagonalnej.

Architektura Hexagonalna – brzmi intrygująco, prawda? Pozwólcie, że w prostych słowach przedstawię to pojęcie: Hexagonalna to rodzaj architektury warstwowej, w której występują tzw. Adaptery/porty ,aplikacja i domena. Cała aplikacja jest podzielona na trzy główne warstwy:

• Warstwa adapterów
• Warstwa aplikacyjna (biznesowa)
• Warstwa domenowa

Poniższy diagram może nieco przybliżyć Wam tę koncepcję. Więcej informacji na temat samej Architektury Hexagonalnej znajdziecie w osobnym poście. Tym razem chciałbym skupić się na jej zaletach i wadach, które mnie osobiście urzekły.

Źródło: https://en.wikipedia.org/

Zacznnijmy od minusów hexagonala.

Jeżeli nie chcesz czytać wyjaśnień wypisałem główne moim zdaniem minusy:

• Lepszy dla Skomplikowanych Projektów
• Wymagany Poziom Wiedzy i Umiejętności
• Zmiana Paradygmatu Programowania
• Zastosowanie DDD w Zależności od Preferencji– tutaj nie wiem czy to minus czy nie, kto co lubi . Sam nie umiem pisać clean DDD wiec daje jako -/+😉
• Podejście wielomodułowe w kontekście gradle oraz maven, może sprawić problemy z konfigurowaniem projektu.

Lepszy dla Skomplikowanych Projektów

Architektura Hexagonalna, choć posiada wiele zalet, niekoniecznie nadaje się do mniejszych projektów. Jej głęboko rozdzielone warstwy domenowe, aplikacyjne i adapterów/portów mogą wymagać tworzenia większej ilości kodu. W przypadku mikroserwisów lub aplikacji o prostych operacjach typu odczytanie wartości lub obsługa żądań CRUD, to rozbicie na oddzielne moduły może stworzyć więcej trudności niż korzyści. W takich sytuacjach może okazać się, że tradycyjne podejście oparte na modelu MVC jest bardziej efektywne

Wysoki próg wejścia dla nowych developerów

Pierwszy raz, gdy zainicjowałem pomysł stworzenia projektu opartego na Architekturze Hexagonalnej, dostrzegłem pewien stopień obaw i zaskoczenia wśród kolegów programistów. Nikt z nich wcześniej nie słyszał o tej architekturze, a tu nagle stawiam na stół nowy koncept. W rzeczywistości zrozumiałem, że przejście do tego podejścia może być nieco przerażające.

Niespodziewanie, schodzimy z utartego szlaku, w którym nasza baza danych i schemat określały, co jest możliwe, a co nie. Ponadto, koncept oddzielenia warstw architektonicznych może wprowadzić pewne zamieszanie: na przykład, aplikacja nie wie nic o adapterach, adaptery nie wiedzą nic o aplikacji, ale wszyscy mają wiedzę na temat domeny, która z kolei jest odizolowana od reszty. Taki sposób myślenia wymaga od nas pewnej przemiany perspektywy. Ale uwierzcie mi warto 😉 trzeba nastawić się ze ajmie trochę czasu zanim developer załapie o co chodzi w tej całej cebuli. Z pewnością warto zdawać sobie sprawę, że zanim developer w pełni zrozumie koncepcję Architektury Hexagonalnej i tę tajemniczą metaforę 'cebuli', może to wymagać pewnego czasu. Podobnie jak przy każdej nowej koncepcji, trzeba być gotowym na pewną fazę nauki i przyswojenia abstrakcyjnych założeń

Często Podejście DDD, ale Nie Zawsze – Czy to Plus, Czy Minus?

Współczesne trendy w tworzeniu oprogramowania często skłaniają się ku Domain Driven Design (DDD), które doskonale współgra z Architekturą Hexagonalną. Jednakże, nie zawsze jest to zasada absolutna, i odkryłem, że istnieją przypadki, gdzie połączenie 'zwykłego' ludzkiego podejścia do kodu z dobrymi praktykami izolacji przynosi również wartość. Czy to jest zaleta, czy wada? To zależy.

Bez wątpienia, podejście DDD w ramach tej architektury jest wyjątkowo skuteczne. Jednak w praktyce ujrzałem, że istnieje możliwość zrównoważonego połączenia typowych praktyk programistycznych z enkapsulacją (co niekoniecznie musi być przerażającym słowem), i to podejście również przynosi pozytywne rezultaty. Warto czasami podjąć chwilę, aby kilkakrotnie przemyśleć, czy dana funkcja lepiej odzwierciedla domenę, czy też kontekst biznesowy. To zrównoważone podejście pozwala na elastyczność i dostosowanie się do specyficznych wymagań projektu, tworząc równowagę między praktycznością a izolacją."

Ogólnikowo ponarzekałem to może przejdźmy do plusów

• Rozdzielenie pomiędzy "Biznesem" a "Logiką Biznesową"- 
• Logika Biznesowa nasza warstwa aplikacji
• Testy
• „Wymienność”
• Czystość kodu

Rozdzielenie pomiędzy "Biznesem" a "Logiką Biznesową"

Rozdzielenie  jest kluczowym aspektem podejścia w architekturze hexagonalnej i ma na celu lepsze zrozumienie oraz modelowanie rzeczywistości biznesowej.

Domena jest tą częścią systemu, która obejmuje fundamentalne zasady, reguły i procesy dotyczące danej dziedziny. To takie "święte miejsce", w którym zachodzą podstawowe interakcje i operacje. Domena reprezentuje rdzeń biznesu i jest miejscem, w którym odzwierciedlane są podstawowe obiekty i ich wzajemne relacje.

Logika Biznesowa nasza warstwa aplikacji to implementacja reguł, polityk i operacji związanych z daną dziedziną. To w tej warstwie umieszczamy kod, który realizuje konkretne zadania i przeliczenia w oparciu o zdefiniowane zasady domeny. Logika biznesowa jest w stanie przetwarzać i manipulować danymi zgodnie z regułami narzuconymi przez domenę.

Dodatkowo Jasne Wytyczenie Granic:

Domena i logika biznesowa mają jasno zdefiniowane role i zakres działania, co pomaga w tworzeniu modułów o odpowiedzialnościach i funkcjonalnościach bardziej klarownych.

Testy

Bez wątpienia, podejście heksagonalne przynosi niezwykłe korzyści w kontekście testowania aplikacji. Teraz mogę cieszyć się perfekcyjnie zdefiniowaną warstwą naszej aplikacji, czyli samą esencją biznesową. To sprawia, że możemy przeprowadzać testy dla niej w sposób całkowicie niezależny od modułów adapterów czy innych elementów domeny. Ta harmonijna izolacja stanowi praktycznie idealne środowisko dla testów jednostkowych.

Wymienność

Wymienność, choć to może nie być dosłowne sformułowanie, odzwierciedla istotę tego, o czym mówię. W podejściu heksagonalnym wyjątkowo sprawnie osiągamy zdolność do wymiany komponentów. Innymi słowy, możemy łatwo wyizolować jeden z adapterów - na przykład bazę danych SQL - i podmienić go na zapytania do silnika wyszukiwania, takiego jak ElasticSearch. Dzięki temu, jasno zdefiniowanym granicom pomiędzy warstwami adapterów a resztą aplikacji, nie muszę się obawiać o integralność całego systemu. Moje starania koncentrują się głównie na implementowaniu interfejsów repozytoriów w warstwie domeny, co zapewnia wyjątkową elastyczność w dostosowywaniu systemu do różnych wymagań i technologii.

Czystość

To ciekawe moim zdaniem spostrzeżenie. Poprzez dążenie do czystości i spójności w podejściu heksagonalnym, stawiamy programistów w punkcie, w którym muszą się zatrzymać i głębiej zrozumieć istotę domeny oraz biznesu. Ta "przymusowa" chwila refleksji pomaga im spojrzeć na całość projektu z bardziej holistyczną perspektywą.

Dzięki wydzielonej warstwie domeny programista jest zachęcany do bardziej ostrożnego i przemyślanego tworzenia kolejnych komponentów. To stymuluje myślenie o tym, jak zbudować daną funkcjonalność w sposób mniej inwazyjny i bardziej zgodny z logiką biznesu, zamiast po prostu stosować gotowe wzorce takie jak "encja", "DTO" czy "REST".

Ten proces pobudza twórczość i skłania do rozważania alternatywnych rozwiązań, które lepiej pasują do danej dziedziny. Dzięki temu osiągamy bardziej przemyślane, spójne i elastyczne rozwiązania, które skupiają się na potrzebach biznesowych, zamiast jedynie podążać za standardowymi technicznymi wzorcami. To także pomaga programistom unikać nadmiernego rozbudowywania modelu lub przekształcania go na zbyt mechaniczne abstrakcje.

W rezultacie, podejście heksagonalne sprzyja głębszemu zrozumieniu domeny, bardziej kreatywnemu myśleniu i wypracowywaniu bardziej dopasowanych rozwiązań, co z kolei przekłada się na bardziej wartościowe i efektywne systemy informatyczne.

Podsumowanie

Bez wątpienia, mogę wymieniać jeszcze wiele korzyści tego podejścia architektonicznego, ale pragnę zachować odpowiednią konieczność. W przyszłym wpisie chciałbym zaś skupić się bardziej na aspektach technicznych, przybliżając fascynujący świat heksagonalnej architektury. Wspólnie zgłębimy techniczne detale i praktyki, które czynią to podejście tak wyjątkowym. Czekam na kolejny etap naszej podróży, gdzie wspólnie odkryjemy piękno heksagona w kontekście praktycznych technik i narzędzi.