Cześć!

Tak jak wspominałem w poprzednich mailach, pracowałem i przeprowadziłem ostatnio warsztaty z Event-Driven Architecture. W ramach warsztatów przeprowadziłem ćwiczenie w grupach, gdzie grupy miały za zadanie zamodelowanie w dowolnym narzędziu następujący problem:

“Celem jest zamodelowanie funkcjonalności fragmentu systemu do zarządzania siecią hoteli. Jest to aplikacja SaaS. Może być używana zarówno do zarządzania sieciami hoteli, jak i konkretnego hotelu. Dostarcza interfejs zarówno dla klienta, który może korzystać z wielu dostępnych sieci hotelowych na całym świecie, jak i przez obsługę hotelową.

Pierwsze wdrożenie będzie robione dla zaprzyjaźnionej sieci hotelowej składającej się z kilku hoteli różnej wielkości i obłożeniu.

Funkcjonalności, które mają być dostępne:

• użytkownik może zrobić rezerwację, zanim się zarejestruje,
• potwierdzenie rezerwacji dostępne jest tylko dla osoby zarejestrowanej,
• użytkownik może zrobić rezerwację samemu przez interfejs naszego systemu, jak i przez booking.com,
• obsługa hotelowa powinna móc zrobić rezerwację dla konkretnego użytkownika,
• obsługa hotelowa powinna mieć funkcjonalność “szybkiego check-in” gdzie będzie mogła szybko dodać konto użytykownika, złożyć rezerwacje i check-in.
• użytkownik ma widzieć swoje rezerwacje i dane pobytu przez aplikację WWW i mobilną,
• obsługa hotelowa powinna widzieć dane rezerwacji w hotelu oraz pobytu użytkowników,
• w momencie zameldowania ma być wystawiona faktura proforma,
• po wycheckoutowaniu powinna zostać wystawiona właściwa faktura”.

Czas na zadanie było około dwóch godzin.

Oczywiście czasu było za mało na zamodelowanie całego problemu, ale nie o to w tym chodziło. Narzędzia każda grupa mogła użyć dowolnego, ale przygotowałem parę sugestii:

• Opis słowny,
• Mind Mapa,
• Event Stormingowy (https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet),
• Diagram C4 (https://c4model.com/),
• Diagram z przepływem,
• Bloczki architektoniczne (zrobione np. w https://www.diagrams.net/),
• mieszane rozwiązanie,
• inna dowolna ulubiona metoda.

Dodatkowo, przygotowałem tablicę w Miro: https://miro.com/app/board/o9J_l9dGpVY=/.

To, co jest ciekawe, w takich zadaniach to obserwowanie jak różni ludzie podchodzą do rozwiązywania problemów w różny sposób. Jedni wychodzą od ogółu do szczegółu, inni zupełnie odwrotnie.

Część skupia się na tym, żeby ładnie to wyglądało i skupiają na samym narzędziu. Inni nie przejmują się formą i zasadami używanego narzędzia, ale “lecą z koksem”.

Każde podejście ma wady i zalety. Chciałbym się podzielić, z Tobą, kilkoma wnioskami opartymi na mojej praktyce jak ja pracuję z modelowaniem i tego typu problemami.

Pierwszym etapem, gdy pracujemy z zupełnie nową funkcjonalnością, jest etap kreatywny. Nie wiemy za dużo, ale potrzebujemy się dowiedzieć, lub po prostu wymyśleć. Dobrą metodą jest tutaj stara dobra burza mózgów. Kilka zasad, którymi warto się kierować w niej to:

• nie ma głupich pomysłów,
• nie krytykujemy, skupiamy się na naszych pomysłach, niecudzych i rzucamy je w eter,
• gdy pomysły się kończą, walczymy jeszcze chwile. To tak jak z bieganiem, często najlepsze efekty powstają, gdy przejdziemy pierwszy próg zmęczenia,
• ważne jednak jest ustalenie maksymalnego czasu trwania burzy mózgów. Nie ma co patrzeć na siłę przed siebie. Zawsze można zorganizować kilka sesji.

Wydaje mi się, że dlatego też takie narzędzia jak Event Storming, Event Modeling i inne “karteczkowe” mają takie wzięcie. Pozwalają one lekceważąco zerwać ze ściany nasz durny pomysł, ewentualnie przestawić go w te lub we wte. Dodatkowo pobudzają dyskusję.

Warto, żeby na takim spotkaniu był rozrzut osób. Zarówno programiści jak i biznes oraz testerzy. Mówimy tutaj o początkowym etapie, więc każda perspektywa się liczy.

Po etapie burzy mózgów warto zrobić odsiew, tego, co wrzuciliśmy. Warto pogrupować pomysły według kategorii. Ważne, żeby też, zanim wyrzucimy pomysły wydające się podobnymi to żeby je przedyskutować. Często w takich detalach leżą ważne elementy, które łatwo przeoczyć.

Sama burza mózgów może dotyczyć konkretnych funkcjonalności jak i globalnej wizji systemu. Event Storming dzieli to na “big picture” i “design level”. Czyli najpierw skupiamy się na zdarzeniach globalnych, następnie schodzimy niżej (przeczytaj więcej o rozróżnieniu zdarzeń na moim blogu: “Events should be as small as possible, right?” https://event-driven.io/pl/events_should_be_as_small_as_possible/).

Mimo, że “big picture” wskazuje, że w Event Storming przechodzimy od ogółu do szczegółu, to według mnie wygląda to trochę inaczej. Punktem wyjścia są zdarzenia, więc same w sobie są już dosyć granularne. Grupując je i ustawiając w kolejności wraz z innymi elementami, wydzielamy moduły systemu (“bounded contexty”). Mając taką wizję, schodzimy znowu niżej, rozbijając funkcjonalności na drobniejsze elementy.

Techniką, która wspiera dobrze wychodzenie od ogółu do szczegółu, jest stara dobra Mapa Myśli. Wychodząc od głównego bloczka, który może oznaczać, np. nasz system, możemy rozbijać na mniejsze szczegóły - np. odpowiadając sobie na pytanie “co jest mi potrzebne, żeby powstała ta funkcjonalność”. Potem możemy rozbijać to analogicznie bardziej i bardziej.

Jest to też dobre narzędzie do metody “5xWhy”. Gdzie możemy zadawać biznesowi kolejne pytania, dlaczego, aby poznać to co jest faktycznym źródłem problemu.

Takie podejścia są bardzo użyteczne, ale często trudno (szczególnie na początku drogi) przełożyć wprost na implementację.

Ciekawym konceptem jest C4, które to pozwala na podział naszego systemu na “kontenery” (nie mylić z dockerowymi kontenerami). Kontenery to w skrócie elementy naszego systemu. Mogą to być moduły, mogą to być warstwy aplikacji, jednostki wdrożeniowe. Wychodzimy od ogólnej wizji systemu i schodzimy coraz niżej. Dzięki temu, dzieląc naszą architekturę na poszczególne poziomy, tworzymy diagramy, które w danym kontekście są czytelne i pozwalają nam zrozumieć, co nasz system robi.

Ja zwykle preferuje podejście od ogółu do szczegółu, ale próbuję zawsze zrobić jakieś “próbne odwierty”. Mam przez to na myśli tunelowe zejście niżej z funkcjonalnościami (szczególnie kluczowymi) i weryfikowanie hipotezy, którą stawiam, robiąc ogólny design. Jest to o tyle ważne, że jeśli tego nie zrobimy, to ryzykujemy, że któraś drobna funkcjonalność okaże się, że jest ślepym zaułkiem i trzeba zmienić ogólny design przez nią.

Inne fajne narzędzia na poziomie już niższym to np. diagramy sekwencji lub aktywności z UML. Pozwalają opisać dokładniej konkretny przepływ. Ważne, żeby był jak najmniejszy, żeby pozostał czytelny. Można zrobić zawsze kilka dla tej samej funkcjonalności.

Oczywiście, opisałem powyżej tylko przykładowe narzędzia, jest ich bardzo dużo. Możliwe, że aż za dużo. Zrobiła się dookoła nich otoczka konsultancka, której osobiście nie lubię. Czasem, czytając niektóre opracowania, wydaje mi się, że niektórzy uważają, że wystarczy użyć metodyki do modelowania i zrobić design, a kod sam się napisze. Tak oczywiście nie jest.

Dla mnie osobiście ważny jest zdrowy rozsądek i dopasowanie narzędzi pod samego siebie. Sam często robię po prostu szkice na kartce. Często zamiast konkretnych metody, to robię sobie bloczki w aplikacji jak diagrams.net (np. https://github.com/oskardudycz/AzurePipelinesSamples). Wszystko dobre co się sprawdza.

Do grupowych dyskusji zalecałbym spróbować zastosowanie gotowych narzędzi (np. Event Storming, C4), bo eliminują one dyskusje typu “jaką metodą głosowania wybierzemy metodę do głosowania”. Potem można sobie to modyfikować według potrzeb je dopasowywać.

Oczywiście nie zawsze jesteśmy w stanie zrobić sobie sesje grupowe. Nie każdy projekt na to pozwala, żeby np. mieć na nich biznes. To jednak nie zwalnia nas z tego, żebyśmy nie spróbowali. Możemy zawsze zrobić sobie sesje design wewnątrz zespołu, a jeśli nasz zespół nie jest chętny, to możemy zacząc od siebie. Od rozrysowania, rozpisania sobie tego, co robimy. Jeśli nam to pomoże i pokażemy innym, to łatwiej nam będzie innych do tego przekonać. W ostateczności, po prostu nam samym będzie łatwiej.

A co jeśli nie wiesz jak to zrobić? Próbuj. Pierwsze razy zwykle są nieudolne. Umiejętność modelowania systemu to umiejętność jak każda inna. Wymaga wprawy i praktyki. Z każdą kolejną próbą będzie łatwiej.

Obecnie jest też łatwiej. Jest też dużo narzędzi, które wspomagają te procesy, aby je utrwalać i katalizować dyskusje również międzyzespołowe. Jeśli chcesz o tym poczytać, daj znać, to postaram się przygotować jakieś przykłady.

Możesz użyć mojego polecenia do zrobienia próbki modelowania ze swoim zespołem albo samotnie. Ważne, żeby zacząć.

Jak Ty podchodzisz do takich tematów?

Pozdrawiam. Oskar