Droga do architektury mikroserwisowej

Podczas projektowania systemu pojawia się wiele założeń i prognoz co do ruchu, obciążenia i wydajności, a pytań może być czasem więcej, niż odpowiedzi. Zdajesz sobie sprawę, z potrzeby posiadania architektury mikroserwisowej, ale nie wiesz jak podzielić wymagania biznesowe na małe, niezależne usługi. Początek prac nad architekturą mikroserwisową nie musi oznaczać tworzenia mikroserwisów. Na szczęście mamy rozwiązanie, które może Ci się spodobać.

Jest to podejście, które prowadzi do mikroserwisów, ale zaczyna się od prostej aplikacji monolitycznej. To, co najważniejsze to taki projekt aplikacji, który umożliwia bardzo łatwe wyodrębnienie każdej części logiki biznesowej do osobnego serwisu. Co więcej, Java natywnie wspiera takie podejście, a wręcz jest zaprojektowana, by właśnie w taki sposób tworzyć aplikacje.  

Brzmi nieźle… więc jak się do tego zabrać?

Chodzi o modyfikatory dostępu i enkapsulację.

W Javie mamy 4 (nie 3!) modyfikatory dostępu: default, public, protected i private oraz 3 poziomy enkapsulacji: class, package and module. Ta wiedza wystarczy, żeby wypełnić nasze założenia.

Na początku musimy podzielić warstwę logiki biznesowej na pakiety. Najważniejsze, by podziału dokonać zgodnie z biznesowymi wymaganiami (odpowiedzialnościami) i ulokować całą związaną z nimi logikę (klasy) w jednym pakiecie. Jeśli podzielimy je dobrze, nie powinny być duże - tak działa enkapsulacja. Każdą część logiki biznesowej umiejscawiamy w jednym spójnym pakiecie, w którym znajdują się wszystkie potrzebne, powiązane informacje. Jeśli chcemy zmienić coś w kwestii przesyłki produktu, szukamy odpowiedniej klasy w pakiecie przesyłki. Kiedy trzeba zmienić logikę zamówień, robimy to w pakiecie zamówień.  Dobrze ilustruje to grafika:

Istotnym aspektem jest utrzymanie jak największej niezależności pakietów, a co za tym idzie: jak najbardziej ograniczonego dostępu do klas i metod. Trzeba do tego wykorzystać domyślny, pakietowy dostęp. Właściwie, prawie wszystkie klasy (tak jak i widoczne w nich metody) w pakiecie powinny być oznaczone tym typem dostępu. Oczywiście, potrzebujemy publicznego interfejsu, wyjątków i klas do transferu danych (DTO, VO) - zasadniczo to wszystkie publiczne elementy. Ogólny schemat dostępu przedstawiony jest poniżej:

Ta - bardzo podstawowa - koncepcja projektowania aplikacji w Javie nie jest często stosowana, ale umożliwia nam wyodrębnienie każdego pakietu i stworzenie nowego, autonomicznego serwisu bez dużego nakładu pracy.

Wszystko, co jest potrzebne dla nowej usługi zawiera się w pakiecie. Po stronie klienta leży tylko implementacja interfejsu tak, aby komunikacja odbywała się przez sieć, zamiast wywoływania metod w samej aplikacji.

Spring Framework również wspiera taką architekturę. Klasy z dostępem domyślnym są bezproblemowo rejestrowane w kontekście. Poza tym, nie wszystkie obiekty muszą być Spring Beans - jedynie te używane w innych pakietach (fasady, kontrolery). Pozostałe mogą być instancjonowane w klasach konfiguracyjnych każdego pakietu.

Dzięki temu programista ma większą kontrolę nad konfiguracją i działaniem aplikacji, a także znacznie ograniczana jest liczba obiektów w kontekście. Dzięki opisanemu podejściu architektura systemu zyskuje na elastyczności i skalowalności. Wraz ze wzrostem zapotrzebowania, każdą część aplikacji można łatwo wyodrębnić lub skalować.