Wprowadzenie
Pięć lat temu artykuł o różnicy między stanem a statusem obiektu kończyłem słowami:
Powyższe to jeden z wielu powodów, dla których metody takie jak “event storming” są bardzo nieskuteczne jako analiza i projektowanie logiki działania oprogramowania, szczególnie tak zwanego “biznesowego”.(Stan obiektu to nie jest jego status – JZ IT Consulting Limited – PL Blog)
Dzisiaj kontynuacja.
Coraz częściej słyszę buzzword “Event-Driven Architecture”. Co to jest? To założenie, że aplikacja to maszyna stanowa, że obiekty reagują i zmieniają swój stan pod wpływem zdarzeń (zmiana stanu innych obiektów) w ich otoczeniu (https://en.wikipedia.org/wiki/Event-driven_architecture). Opis w postaci prezentacji link poniżej:
https://youtu.be/gOuAqRaDdHA?si=lwK0jW8ekeV_ukHa
Tak więc logika “systemu” to “maszynach stanów” tych obiektów. Brzmi fajnie, nie?
Dlaczego więc tak wiele projektów oprogramowania kończy się niepowodzeniem? Są to próby tworzenia aplikacji w formie dużych zespolonych maszyn stanowych, które zmieniają stan dużej bazy danych. Niestety, model ten jest najbardziej nienaturalny, ponieważ my, jako ludzie (jako firmy, jako agencje rządowe), wymieniamy się wiadomościami (komunikaty), my nie zmieniamy stanu “wspólnej bazy danych”.
Dlatego naturalną architekturą systemu informatycznego jest zespół komponentów i komunikaty między nimi, a nie system jako “wielka maszyna stanowa”. Paradygmat obiektowy to enkapsulacja, polimorfizm i wymiana komunikatów, a nie “obiekty, dziedziczenie i ich stany” (Alan Kay).
Skuteczne wzorce projektowe to skoordynowane, enkapsulowane komponenty, które wymieniają i przechowują komunikaty (dokumenty), a nie duże monolityczne maszyny stanowe. Tymi podstawowymi wzorcami są:
- SAGA na poziomie HLD (komponenty)
- łańcuch odpowiedzialności na poziomie LLD (wnętrze komponentu: klasy)
- koperta jako wzorzec komunikacyjny z repozytorium dla trwałości (JSON, XML, np. repozytoria NoSQL key-value lub dokumentowe).
W biurze i na budowie
Popatrzmy na ten model procesu biznesowego:
Mamy tu pięć aktywności, każda nich to określona procedura oraz inicjujący ją dok. wejściowy oraz jej produkt, czyli wyjściowy dokument (nowy z zmieniony). Cały ten diagram to jedna logika obsługi zapytań. Każdy z wykonawców określonej procedury (task w BPMN) zna tylko swoją część. Kolejność tych procedur (łączące je strzałki) wynika z treści każdej z nich: od kogo można przyjąć polecenie oraz komu i kiedy przekazać efekt pracy.
UWAGA! To dlatego bez modeli procesów biznesowych nie jest znana logika działania całości firmy, żadna procedura ani jej wykonawca nie zna całego procesu i logiki całości! Bez takiego diagramu weryfikacja spójności i kompletności procesów jest niemożliwa.
Dlatego norma jakości ISO 9001, od 2003 roku WYMAGA by istniał model pokazujący (walidujący) proces: łańcuchy procedur stanowiące sobą spójny i kompletny proces (procesy). Powody są proste: nie istnieje inna metoda by to zaprojektować lub sprawdzić. Alternatywą jest osoba organizatora tej pracy wydająca we właściwym czasie, właściwym osobom właściwe polecenia. Możemy ją nazwać liderem ale wtedy mamy niezgodność z normą: wiedza w głowie lidera a nie “na papierze”.
Wyobraźmy sobie, że wiedza o tym kto komu przekazuje efekty pracy i od kogo, zostanie usunięta z diagramu (ta wiedza jest ukryta, zakodowana, wewnątrz tych zadań: w procedurach), wtedy ten diagram wyglądał by tak:
To jest typowa sytuacja, w której nauczeni długą praktyką ludzie wykonują swoją pracę poprawnie, każdy wie co ma robić i kiedy, ale nie istnieje wiedza nadrzędna, czyli nie wiadomo jak to działa jako całość. Ten diagram to stan, w którym znamy nazwy etapów pracy i nic ponad to. Ten diagram pokazuje także, że jakakolwiek ingerencje w ten proces, chęć jego zmiany, to kolejna walka po omacku, metodą prób i błędów. Przeprojektowanie takiego procesu wymaga: przeglądu i aktualizacji procedur, stałej obserwacji skutków i natychmiastowego reagowania na problemy. Każda zmiana to okres “docierania się” i intensywna praca szefa działu, a nie raz dyrektora generalnego. Takie reorganizacje w firmach robi się rzadko a ostateczna wersja “nowego ładu” powstaje metodą prób i błędów.
Wyobraźmy sobie, że nie to ludzie, a tylko roboty wykonujące napisane dla nich (przez kogoś) procedury. Logika (wiedza o tym co i dlaczego sie dzieje) tak zorganizowanego systemu jest “rozsmarowana” po “całym systemie”: każdy robo ma jej fragment. O czym pisze? Aplikacje (oprogramowanie) to proceduralne roboty.
Coś większego: plac budowy. Wyobraźmy, że to, co dzieje się (powinno się dziać) na placu budowy, jest zagregowaną reakcją wszystkich robotników (aktualny “stan planu budowy”) na to, co każdy z nich zaobserwuje w swoim otoczeniu. Innymi słowy, każdy pracownik na placu budowy musi wiedzieć, jak zachowywać się w odpowiedzi na to co zobaczy a wariantów jest wiele. Jak dużą wiedzę musi posiadać każdy z tych robotników? Co się stanie, jeśli choć jeden z nich zachowa się “źle”? Zapanuje chaos! Co trzeba zrobić, aby taki system zmienił zachowanie? Trzeba przejrzeć i zaktualizować zachowania (instrukcje stanowiskowe i zakresy obowiązków) wszystkich i się nie pomylić przy ich modyfikacji!
W czym tkwi problem?
Wyobraź sobie, że plan budowy to maszyna stanowa. Jak wyglądał by tu “diagram maszyny stanowej” co on by realnie pokazywał?
Jeśli masz wątpliwości, spróbuj narysować model takiej architektury i diagram sekwencji dla każdego bodźca zewnętrznego zmieniającego stan całości. Pamiętaj: jeśli coś jest trudne do narysowania, jest jeszcze trudniejsze do wdrożenia.
Tak więc uznanie, że logika systemu to maszyny stanów obiektów systemu, jest “drogą do śmierci”. Poniżej efekty “drobnych mikroserwisów” i architektury “event-driven”:
Czy można inaczej?
Tak: ludzie na budowie mają skupić się na swojej specjalizacji, a potrzebny jest szef który osiąga wymagane efekty wydając właściwe polecenia, właściwym ludziom, we właściwym czasie i właściwej kolejności. To wzorzec architektoniczny, stara dobra SAGA i mikroserwisy, czyli wyspecjalizowane zaplecze i koordynator dla każdego przypadku użycia systemu (każdego zlecenia dla ekipy budowlanej) . Poniżej jeden w wielu opisów:
API Gateway to także koordynator: żądania od klienta są realizowane poprzez wywoływanie w odpowiedniej kolejności dedykowanych dziedzinowych komponentów (mikro-serwis). Patrz także Taktyczny DDD. Poniżej praktyczny przykład:
Jeżeli zdarzy się, że “coś poszło nie tak”, projektujemy dodatkowy scenariusz:
Podsumowanie
Kluczowym miernikiem jakości oprogramowania jest koszt całego cyklu życia a ten jest niemalże w 100% zależny od jego architektury . Architektury komponentowe (mikro-serwisowe) zorientowane na komponenty dziedzinowe i ich koordynację, mają tu ogromną przewagę nad “autonomicznymi federacjami komponentów”. Te drugie bardzo szybko prowadzą do sytuacji w której aplikacja staje się monolitem, w którym logika biznesowa: realizowane funkcjonalności, jest “rozsmarowana” po całym kodzie. W efekcie system projektowany jako maszyna stanowa lub federacja maszyn stanowych powoduje, że koszty cyklu życia takiego systemu rosną wykładniczo.
Przykłady projektów w moim Portfolio.
