Jak cholerę zwał tak zwał. Generalnie ostatnie spotkania Wrocławskiego JUGa dały mi trochę do myślenia.

Pierwsze z Wujkiem Bobem było poświęcone Clean Architecture. Wcześniej Andrzej Bednarz opowiadał nam o swoich doświadczeniach z tym rozwiązaniem, ale tu mieliśmy okazję „u żródła”.
Drugie poświęcone architekturze mikroserwisów poprowadzone przez Roberta Firka było swoinstym dopełnieniem.

O co chodzi?

Clean Architecture jest koncepcją takiego tworzenia funkcjonalności by były one jak najbardziej odseparowane od świata zewnętrznego. Interaktor (ciężko mi znaleźć polskojęzyczny odpowiednik) ma swój interfejs komunikacyjny i korzysta z pewnych obiektów – encji domenowych (wspólnych dla wielu aplikacji nie tylko dla tej konkretnej). Gdy potrzebuje dostać się do danych korzysta z interfejsu dostępowego, ale nie DAO lecz czegoś w rodzaju gateway-a. Co jest za nim… who cares. Po prostu dostajemy dane w pewnym określonym formacie i czy będzie pod spodem baza danych, czy jakiś sawant… W efekcie dostajemy aplikację, która ma charakter kontenera pluginów. Jest sobie jakiś core biznesowy reprezentujący use casy, a reszta to tylko łatwo wymienialne pluginy.

Mikroserwisy są znowuż podejściem gdzie stawiamy duży nacisk na separację poszczególnych funkcjonalności i ich niezależność. W tym podejściu liczy się przede wszystkim duża granulacja kodu, tak by zmiana nie trwała tygodniami, a raczej godzinami. Poszczególne fragmenty komunikują się ze sobą i każde wywołanie powinno nieść ze sobą wszelką wiedzę i informacje potrzebną do wykonania danej operacji. Mikroserwisy mogą powstawać w różnych technologiach i nie mogą współdzielić zasobów.

Widzicie na czym polega myk?

Mikro architektura, czyli clean services

Projektowanie zaczynamy zgodnie z Clean Architecture. Naszą bazą mentalną jest konkretny use case. Reprezentuje on jeden niezależny scenariusz w aplikacji. W tym momencie projektujemy kod, spisując kolejne kroki i korzystając z bazy pojęć CA. Mamy więc interaktora, boundaries, entyties, gateways.
Następnie zaczynamy kod pisać i na poziomie pojedynczego use casa nadal trzymamy się CA.
Gdy jednak dokładamy realizację elementów „plugowalnych” chociażby jakiś testowy gateway to staje się on mikroserwisem. Staramy się tak zaprojektować interfejs by wywołanie jakiegoś pluginu realizowane było w oparciu o MiS.

Co to nam daje?

Dwa słowa podsumowania. CA i MiS są to dwa podejścia, które kładą nacisk na dwa inne elementy architektury. W CA staramy się modularyzować kod tak by reprezentował on poszczególne zagadnienia biznesowe. Każdy niezależny element w kodzie ma odbicie w use caseie. MiS kładzie znowuż nacisk na to jak poszczególne moduły ze sobą współpracują oraz na to by awaria jednego z nich nie wywaliła nam aplikacji.
Moim zdaniem połączenie tych dwóch podejść pozwala na stworzenie z jednej strony aplikacji, która będzie dość odporna na awarie. Jednocześnie każda pojedyncza jednostka organizacyjna będzie miała jasno określony zakres odpowiedzialności biznesowej.
Ponad to, jako że w każdej aplikacji istnieją pewne byty konieczne z punktu widzenia prawidłowego działania, ale nie niezbędne biznesowo (administracja uprawnieniami, składowanie danych, audyt), będzie można tak zorganizować kod by ich istnienie miało jak najmniejszy wpływ na logikę biznesową.