Przejd┼║ do tre┼Ťci

Architektura Hexagonalna [Cebula/Porty i Adaptery] ­čöą­čĹŹ

Architektura Hexagonalna znana te┼╝ jako Onion Architecture lub Ports & Adapters zosta┼éa wymy┼Ťlona przez Alistaira Cockburna┬ái opublikowana w 2005 roku. Jej celem jest unikni─Öcie znanych pu┼éapek strukturalnych w OOP jak np. zale┼╝no┼Ťci mi─Ödzy wartswami czy te┼╝ wplatanie kodu odpowiedzialnego za GUI do warstwy logiki biznesowej. Ma ona na celu stworzenie lu┼║no powi─ůzanych komponent├│w aplikacji, kt├│re mo┼╝na ┼éatwo po┼é─ůczy─ç za pomoc─ů port├│w i adapter├│w. To sprawia, ┼╝e komponenty s─ů wymienialne na ka┼╝dym poziomie i u┼éatwia automatyzacj─Ö test├│w.


Cze┼Ť─ç┬á­čÖé

To jest ju┼╝ trzeci wpis z mini-serii blog├│w┬áo architekturach aplikacyjnych. W poprzednich wpisach mog┼ée┼Ť przeczyta─ç o

W dzisiejszym artykule dowiesz si─Ö:


Czym jest architektura hexagonalna

Celem architektury hexagonalnej jest umo┼╝liwienie, aby aplikacja kt├│r─ů rozwijamy by┼éa traktowana tak samo przez u┼╝ytkownik├│w, programy zewn─Ötrzne, testy czy te┼╝ skrypty. Dodatkowo ma ona umo┼╝liwia─ç rozw├│j i testowanie aplikacji w oderwaniu od zewn─Ötrznych zale┼╝no┼Ťci (baza danych / zewn─Ötrzne API).

Architektura hexagonalna w centrum aplikacji stawia na przypadki u┼╝ycia i domen─Ö – to te┼╝ jest pow├│d dlaczego sprawdza si─Ö ona dobrze z DDD. Warto zauwa┼╝y─ç, ┼╝e ten styl architektoniczny jest przeciwny architekturze wartstwowej – tutaj zale┼╝no┼Ťci s─ů kierowane do ┼Ťrodka domeny a nie jak w przypadku warstw od g├│ry do do┼éu.

 

Nazwa architektury wzi─Ö┼éa si─Ö z efektu wizualnego jaki przedstawia hexagon – wi─Öcej o tym przeczytasz w artykule Alistair’a Cockburn’a, tw├│rcy architektury:

The hexagon is not a hexagon because the number six is important, but rather to allow the people doing the drawing to have room to insert ports and adapters as they need, not being constrained by a one-dimensional layered drawing. The term ÔÇśÔÇÖhexagonal architectureÔÇÖÔÇÖ comes from this visual effect.


Jak wygl─ůda struktura hexagonu

Hexagon sk┼éada si─Ö z trzech kluczowych element├│w: domeny (core), port├│w i adapter├│w. Je┼╝eli spojrzymy na hexagon zaprezentowany na rysunku powy┼╝ej mo┼╝na te┼╝ zauwa┼╝y─ç, ┼╝e nasz core (domena i przypadki u┼╝ycia) u┼╝ywaj─ů port├│w – czyli domena wie na co dany port pozwala, np. zapis u┼╝ytkownika ale nie wie jak to si─Ö stanie. I do tego w┼éa┼Ťnie s┼éu┼╝─ů adaptery. Aplikacja mo┼╝e mie─ç np. prawdziw─ů baz─Ö danych, kt├│ra rzeczywi┼Ťcie zapisze u┼╝ytkownika w bazie ale mo┼╝e to te┼╝ by─ç hashmapa, kt├│ra po restarcie aplikacji nie b─Ödzie ju┼╝ niczego pami─Öta─ç.

Porty dziel─ů si─Ö na wej┼Ťciowe i wyj┼Ťciowe. Wej┼Ťciowe to te, kt├│re steruj─ů nasz─ů logik─ů np. GUI, gdzie u┼╝ytkownik wywo┼éuj─Ö dan─ů akcj─Ö. Wyj┼Ťciowe s─ů u┼╝ywane (sterowane) przez logik─Ö biznesow─ů. Tutaj najlepszym przyk┼éadem s─ů bazy danych i zewn─Ötrzne API. Aplikacja musi porozumie─ç si─Ö z jakimi┼Ť zewn─Ötrznymi komponentami i w tym celu u┼╝ywa w┼éa┼Ťnie port├│w wyj┼Ťciowych.

Domena

S─ů to nasze obiekty domenowe. Ich implementacja powinna by─ç na tyle jasna, ┼╝eby nawet kto┼Ť nie techniczny m├│g┼é podej┼Ť─ç i powiedzie─ç ok, rozumiem co tu si─Ö dzieje. Obiekty domenowe nie powinny mie─ç ┼╝adnych zewn─Ötrznych zale┼╝no┼Ťci. Domena opisuje jak co┼Ť zrobi─ç.

Przypadki u┼╝ycia

To klasy, kt├│re obs┼éuguj─ů konkretne problemy biznesowe. Jest to faktyzcna warto┼Ť─ç dla biznesu, kt├│ra rozwi─ůzuje ich problem. Przypadki u┼╝ycia mog─ů zawiera─ç wszystkie niezb─Ödne walidacje i logik─Ö regu┼é biznesowych, kt├│re s─ů specyficzne dla konkretnego przypadku u┼╝ycia (dlatego te┼╝ nie mog─ů by─ç implementowane w obiektach domeny) a nast─Öpnie deleguj─ů prac─Ö do domeny. Use case’y nie s─ů zale┼╝ne od zewn─Ötrznych komponent├│w, natomiast je┼╝eli potrzebuj─ů czego┼Ť z zewn─ůtrz (np. pobranie u┼╝ytkownika) to tworz─ů do tego port (albo u┼╝ywaj─ů istniej─ůcego). Przypadki u┼╝ycia m├│wi─ů co zrobi─ç.

Porty wej┼Ťciowe i wyj┼Ťciowe

Porty mo┼╝esz sobie wyobra┼╝a─ç dok┼éadnie tak jak porty w komputerze, np. USB. Nie jest wa┼╝ne czy pod┼é─ůczysz urz─ůdzenie firmy X czy Y – oba powinny dzia┼éa─ç.

W architekturze hexagonalnej komunikacja do i z aplikacji odbywa si─Ö przez porty. Port wej┼Ťciowy b─Ödzie zazwyczaj interfejsem, kt├│ry jest implementowany przez konkretny przypadek u┼╝ycia. Podobnie jest z portem wyj┼Ťciowym – to r├│wnie┼╝ b─Ödzie interfejs. Tym razem jednak przypadek u┼╝ycia b─Ödzie go u┼╝ywa┼é – a nie tak jak w przypadku portu wej┼Ťciowego implementowa┼é.

Dzi─Öki portom wej┼Ťciowym i wyj┼Ťciowym mamy bardzo wyra┼║ne miejsca, w kt├│rych dane wchodz─ů i wychodz─ů z naszego systemu, u┼éatwiaj─ůc rozumowanie na temat architektury.

Adaptery

Adaptery tworz─ů zewn─Ötrzn─ů warstw─Ö architektury hexagonalnej. Nie s─ů cz─Ö┼Ťci─ů rdzenia, ale wchodz─ů z nim w interakcj─Ö. Adaptery r├│wnie┼╝ dzielimy na dwie grupy: wej┼Ťciowe i wyj┼Ťciowe. Wej┼Ťciowe (lub steruj─ůce) wywo┼éuj─ů porty wej┼Ťciowe, aby co┼Ť zrobi─ç w aplikacji – w ko┼äcu wywo┼éuj─ů konkretny przypadek u┼╝ycia. Wyj┼Ťciowe (sterowane) s─ů natomiast wywo┼éywane przez przypadki u┼╝ycia.

Adaptery u┼éatwiaj─ů wymian─Ö okre┼Ťlonej warstwy aplikacji, np. zmiana bazy danych na inn─ů. Wystarczy napisa─ç tylko nowy adapter.


Wady i zalety architektury

Zalety:

    • testowalno┼Ť─ç
    • rozwijalno┼Ť─ç i utrzymanie
    • wymiana technologii

Wady:

    • trudniejsza nawigacja po kodzie ┼║r├│d┼éowym – musimy ogarnia─ç co, gdzie jest u┼╝ywane
    • wiele adapter├│w = wiele test├│w

Podsumowanie

W tym kr├│tkim wpisie chcia┼éem przedstawi─ç Ci ide─Ö architektury hexagonalnej. Je┼╝eli czyta┼ée┼Ť wcze┼Ťniejsze artyku┼éy to zapewne ju┼╝ wiesz, ┼╝e u┼╝ycie konkretnej architektury zale┼╝y od tego czego chce biznes. W przypadku architektury hexagonalnej dobrym wyborem jej zastosowania wydaj─ů si─Ö by─ç projekty o zmiennej i z┼éo┼╝onej logice biznesowej. Natomiast zastosowanie jej w CRUD-ach b─Ödzie zdecydowanie przesad─ů i przerostem formy nad tre┼Ťci─ů. Zamiast upro┼Ťci─ç zrozumienie, mo┼╝esz je tylko niepotrzebnie skomplikowa─ç.

Źródła:


Za tydzień

Moja lista todo robi si─Ö coraz d┼éu┼╝sza… jednak zanim zaczn─Ö j─ů czy┼Ťci─ç (mo┼╝e powinienem pisa─ç 2 artyku┼éy tygodniowo) chcia┼ébym doko┼äczy─ç seri─Ö o architekturach aplikacyjnych. Dlatego te┼╝ za tydzie┼ä opiszemy popularn─ů architektur─Ö mikroserwis├│w.

5 2 votes
Article Rating
Subscribe
Powiadom o
guest
3 komentarzy
najnowszy
najstarszy oceniany
Inline Feedbacks
View all comments
Damian
Damian
2 lat temu

yo, fajny artyku┼é, mam pytanie odno┼Ťnie fragmentu tekstu ” Przypadki u┼╝yciaTo klasy, kt├│re obs┼éuguj─ů konkretne problemy biznesowe. Jest to faktyzcna warto┼Ť─ç dla biznesu, kt├│ra rozwi─ůzuje ich problem. Przypadki u┼╝ycia mog─ů zawiera─ç wszystkie niezb─Ödne walidacje i logik─Ö regu┼é biznesowych, kt├│re s─ů specyficzne dla konkretnego przypadku u┼╝ycia (dlatego te┼╝ nie mog─ů by─ç implementowane w obiektach domeny) a nast─Öpnie deleguj─ů prac─Ö do domeny.” nie rozumiem do ko┼äca podzia┼éu przypadk├│w u┼╝ycia i domeny w tym opisie rozumiem to tak, ┼╝e przypadki u┼╝ycia s─ů wystawionym API z modu┼éu(opisanym jako port wej┼Ťciowy w Twoim artykule) i one bezpo┼Ťrednio kieruj─ů ruch do domeny, kt├│ra posiada walidacj─Ö i… Czytaj wi─Öcej ┬╗

Czarek
3 lat temu

Cze┼Ť─ç!

Dzi─Öki za wyja┼Ťnienie architektury Ports & Adapters. Koncepcja nie wydaje si─Ö trudna i daje sporo mo┼╝liwo┼Ťci, ale pewnie trzeba sp─Ödzi─ç z ni─ů troch─Ö czasu, aby znale┼║─ç jej ciemne strony ­čśë Wykorzystywa┼ée┼Ť j─ů mo┼╝e w jakim┼Ť projekcie produkcyjnym?

Pozdrawiam

3
0
Would love your thoughts, please comment.x