Porty i adaptery

Ostatnio pisałem o pracy z zastanym kodem. Za to dziś pora na coś z drugiego bieguna. Tym czymś jest wybór architektury. Dla wielu projektów architektura jest jedną z pierwszych decyzji do podjęcia. W niektórych przypadkach odpowiada za nią architekt, w innych  duży wpływ na nią mają programiści. Dlatego jedną z architektur które można rozważyć to porty i adaptery.

Porty i adaptery – nazwy

Porty i adaptery (ports and adapters) posiadają inną nazwą – hexagonal architecture. Również bardzo zbliżone założenia mają onion architecture oraz clean architecture. W każdym z tych podejść ważny jest core, który dobrze współgra z DDD.

Core

Znajduje się w samym centrum hexagonu. Ponieważ zawiera obiekty domenowe oraz logikę biznesową. Ponadto nie ma tutaj żadnych frameworków. Po prostu czysty kod w danym języku i nic więcej.

Porty

Służą do wywołania logiki domenowej. Znajdują się one na krawędziach hexagonu i należą do core’u aplikacji. Istnieją ich dwa rodzaje.

Primary/Driver ports

W większości przypadków będą to serwisy, które zawierają logikę biznesową. Przykładem jest UI port na powyższym rysunku.

Secondary/Driven ports

Zazwyczaj są to interfejsy, które służą do komunikacji ze światem zewnętrznym. W moim przykładzie to jest DB port.

Adaptery

Głównym zadaniem adapterów jest przetworzenie żądań, które zawierają technologię na język domenowy oraz operacje odwrotne. Także dla nich istnieją dwie grupy.

Primary/Driver adapters

Służą do zamiany requestów związanych z frameworkiem na żądania które są zrozumiałe przez core aplikacji. Te adaptery wywołują primary ports, czego przykładem jest UI adapter.

Secondary/Driven adapters

Zazwyczaj są implementacją interfejsów z secondary ports. To właśnie tutaj pojawiają się interakcje z bazą, komunikacja z zewnętrznymi usługami. Dlatego można je nazwać infrastrukturą.

Architektura hexagonalna plusy i minusy

Jak każde podejście porty i adaptery mają swoje dobre i złe strony o których warto wiedzieć podczas wyboru.

Wady

• może istnieć wiele klas pośrednich. Powodem tego jest tłumaczenie obiektów domenowych na niedomenowe.
  
• skomplikowanie. Dla osób które nie pracowały z tym rodzajem architektury próg wejścia może być wyższy. Ale dzięki programowaniu w parze z doświadczona osobą można ten problem rozwiązać.
  

Zalety

• core bez zewnętrznych zależności. Dzięki temu bardzo łatwo można rozpocząć prace aplikacją. Co może skutkować szybko dostępnym prototypem.
  
• łatwa do testów. Skoro core aplikacji nie posiada zewnętrznych zależności to przetestowanie logiki domenowej jest proste. Ponadto stworzenie portu, który ma storage w pamięci jest również proste.
• opóźniony wybór technologii. Początkowo podczas startu projektu nie trzeba decydować jaką bazę, frameworku użyć. Z tego powodu decyzję można odłożyć do czasu gdy już posiadamy wiedzę co jest potrzebne.
  

Czy stosować porty i adaptery

Na to pytanie można odpowiedzieć tylko w jeden sposób:

To zależy.

Na pewno przy CRUDach, niewielkich aplikacjach raczej nie proponowałbym tej architektury. Jednak w przypadku aplikacji, które zawierają logikę domenową, mają zmienne wymagania czy istnieje prawdopodobieństwo  zmiany technologii to wtedy architektura hexagonalna jest warta rozważenia.

Ponadto jeśli ktoś jest zainteresowany to w poniższych książkach są rozdziały odnośnie architektury hexagonalnej oraz czystej architektury.
DDD dla architektów oprogramowania
Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów