Serwis serwisowi nierówny

Gdy projektujemy w SOA pojawia nam się wiele serwisów. Jak je ułożyć? Jakie są zależności między nimi? Który serwis korzysta z innych? Tutaj opiszę trzy rodzaje serwisów w aplikacji

Zachęcony licznymi (dwoma) mailami wracam do blogowania. :)

Niedawno ;) pisałem o architekturze opartej o serwisy. Ale warstwa serwisów nie jest jednolita. Jeśli całe działanie aplikacji oprzemy na serwisach a kontrolery będą jedynie wywoływać akcje serwisów, możemy wyróżnić kilka rodzajów serwisów. Warto myśleć pod tym kątem projektując aplikację.

Zacznijmy od najprostszych:

Serwisy Infrastruktury (Infrastructure Services)

Najłatwiejsze do zrozumienia. To serwisy, które robią rzeczy niezależne od ligiki samej aplikacji. Wysyłanie maili, logger, połączenie z bazą danych, zarządzanie kolejką, pobranie aktualnego użyszkodnika. To wszystko infrastruktura.

Co te serwisy mają ze sobą wspólnego?

  1. Są to ogólne serwisy, nie związane z konkretną częścią aplikacji. Np. wysyłanie maili można zastąpić wysyłaniem wiadomości na facebooku a i tak zasadnicze działanie aplikacji się nie zmieni.
  2. Używamy ich w wielu miejscach w różnych modułach aplikacji. Nie są stricte związane z danym modułem.
  3. Często są to zewnętrzne elementy, kod dostarczony przez innego dostawcę. Nie są ściśle związane z naszym biznesem.

W moim ulubionym Symfony mamy ogromną ilość serwisów infrastruktury: bazy danych (doctrine), swiftmailer, logger, Guzzle (do pobierania www) – to wszystko serwisy infrastruktury. Używamy ich ponownie w kolejnych aplikacjach. Bardzo często nie piszemy ich sami tylo pobieramy z sieci, konfigurujemy i używamy.

Takie serwisy mogą wywoływać inne serwisy infrastruktury (np. logger wywołuje wysyłanie maili) ale nie komunikują się z pozostałymi typami serwisów.

Serwisy Aplikacji (Application Services)

Kiedyś, w czasach misz-maszu architektury podobną rolę pełniły kontrolery. Serwis aplikacji zajmuje się wykonywaniem akcji w systemie. Jeśli mamy akcję np. “zarejestruj nowego użytkownika” albo “realizuję zamówienie w sklepie” – odwołujemy się do serwisu aplikacji.

Można o nich myśleć jako o komendach, przypadkach użycia (Use Cases), pojedynczych pracach (Unit of work) – o tym co faktycznie wykonujemy z zewnątrz na aplikacji.

Wywołanie takiego serwisu może oznaczać wiele akcji. Może on pobrać zalogowanego użytkownika (z serwisu infrastruktury), dodać nowy produkt do jego profilu (serwis domeny) i zalogować akcję (znów serwis infrastruktury).

Serwisy Domeny (Domain Services)

To nasze mięsko (lub soja dla wegetarian). Serwisy Domeny zajmują się naszą domeną, logiką biznesową czyli tym, do czego aplikacja została stworzona. Jeśli robimy sklep, naszą domeną będzie zarządzanie bazą produktów, ich cen, katalogiem i stanem magazynowym. W aplikacji medycznej zajmujemy się pacjentami, lekarzami, chorobami, receptami i wizytami.

Taki serwis pracuje bezpośrednio na obiektach domeny. Te obiekty to właśnie produkty, spotkania, recepty czy katalogi. Swerwisy domeny mówią językiem biznesu, dla którego tworzymy aplikację.

Serwisy domeny mogą rozmawiać z innymi serwisami domeny oraz z serwisami infrastruktury ale nie wywołują serwisów aplikacji.

Praktyczny przykład

Załóżmy, że mamy sklep internetowy. Użytkownik dodał do koszyka produkty i teraz klika w zamówienie. Jak to wygląda w serwisach? Serwis aplikacji wykonuje komendę “złóż zamówienie”:
serwisy

  1. Pobierz bieżącego użytkownika (z serwisu infrastruktury)
  2. Pobierz zawartość koszyka tego użytkownika (z serwisu domeny)
  3. Przenieś produkty z koszyka do zamówienia (do serwisu domeny)
  4. Oznacz zamówienie jako złożone (w serwisie domeny)
  5. Wyślij e-mail z potwierdzeniem (w serwisie infrastruktury)

W powyższym przykładzie już serwis domeny (zamówienia) mógłby wysłać maila do użyszkodnika. Dla zachowania czystości wysyłamy jednak maila z serwisu aplikacji.

Co wywołuje serwis aplikacji? Może być wywołany z kontrolera. Może być uruchomiony przez komendę shella. Może być wywołany poprzez kolejkę zdarzeń (event queue) przez zdarzenie nakazujące złożenie zamówienia.

Co dalej?

O opisanych typach serwisów możemy przeczytać w wielu artykułach. Tutaj, tutaj i tutaj jest jasno opisane na czym polegają. Opis tych serwisów znajdziemy też w książce Domain-Driven Design.

2 myśli na temat “Serwis serwisowi nierówny”

  1. “pobranie aktualnego użyszkodnika” to nie jest przypadkiem service aplikacji zamiast infrastruktury? :)

    1. To zależy. Jeśli masz REST API, które wystawia informację “moje konto” to może być to w serwisie aplikacji. Jeśli natomiast Twój serwis wystawia akcje typu “zasil konto”, “wyślij wiadomość do..” itp, to zawsze akcja w serwisie aplikacji musi wiedzieć kim jestem. Pobiera więc aktualnego użytkownika. To czysto techniczne zadanie.

      Wyobraźmy sobie to tak:
      – Serwis domeny operuje na użytkownikach, może przesyłać wiadomości, aktualizować konta itp. Jest bezstanowy, każda akcja musi dostać info na którym użytkowniku operuje.
      – Serwis aplikacji daje komendy typu wyślij maila do… itp. Musi skądś wiedzieć kto maila wysyła sięga więc do…
      – Serwisu infrastruktury, który daje aktualną sesję a potem drugiego, który na podstawie danych z sesji daje obiekt aktualnego użytkownika.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *