Mam pomysł na apkę z serii „do poćwiczenia”. Będzie to system rezerwowania sal w firmie. Jest to przymiarka do trochę innego zadania, które obecnie nazywam „głównym projektem”.

Architektura – zarys

Mamy dwa główne elementy z których chcemy korzystać. Pierwszy to baza (jakaś, nie koniecznie baza danych) użytkowników, którzy pracują sobie w biurach. Drugi to informacja o salach w poszczególnych lokalizacjach. To spinamy w ramach komponentu zwanego „rezerwacje”. UMLa nie będzie, bo nie chce mi się szukać pluginu do rysowania w WP.
Komponenty mają dobrze zdefiniowane interfejsy i generalnie potrafią się „dogadać” za pomocą REST-WS. I to w praktyce jest jedyne ograniczenie projektowe – jak coś robisz to musi to gadać z resztą po restach i w jsonie. Nie ważne jest czy będzie to pod spodem Java, Railsy, Go, Erlang czy pociąg hindusów. Sposób komunikacji jest jasny i precyzyjny.
Oznacza to, że komponenty będą wobec siebie niezależne na poziomie platformy. Zależności biznesowych się nie pozbędziemy.

Architektura – pomysł na implementację

Skoro całość ma być wzajemnie niezależna to rozsądnym wydaje się wykorzystanie mikroserwisów. Spełniają one warunek wzajemnej niezależności oraz pozwalają na wymuszenie określonej formy komunikacji. Żadnych RMI, żadnych SOAP-ów, a jedynie REST. To nawet COBOL potrafi obsłużyć.
Zatem każdy z modułów będzie sobie śmigał jako niezależny serwis. Oczywiście na poziomie biznesowym będą one zależne, ale awaria jednego z serwisów nie powinna wpłynąć na inne. Co najwyżej wyłączy część funkcjonalności (w myśl zasady, że na pochyłe drzewo i salmonella nie naleje).

Przeprowadźmy zatem krótką analizę zależności na poziomie biznesowym oraz wpływu awarii na poszczególne komponenty.

Użytkownicy (i Sale)

Komponent niezależny. Awaria innych komponentów nie ma na niego wpływu. Ma ukrytą zależność na poziomie implementacji w postaci „jakiegoś” elementu zapisującego dane (baza relacyjna, plik, proviler). Awaria tego elementu spowoduje awarię komponentu.

Rezerwacje

Komponent zależy od dwóch powyższych. Awaria jednego z nich spowoduje ograniczenie możliwości komponentu. Tworzenie i zmiana rezerwacji będzie niemożliwe ponieważ nie będzie można odczytać informacji o salach i użytkownikach. Usuwanie rezerwacji będzie możliwe. Odczyt części informacji o rezerwacji będzie niemożliwy (szczegóły użytkownika/sali).
Komponent ma zależność używaną do składowania danych. Awaria w tym miejscu wyłącza komponent z użycia.

Jak zatem widać współpraca komponentów może oznaczać, że wraz z awarią jednego z nich inne będą miały ograniczone możliwości.

Podsumowanie

Ideę znamy można by to zaimplementować…