Cześć !

Spędziliśmy już razem trochę czasu przy poprzednich mailach. Mam nadzieję, że jak na razie wszystko w Twojej głowie odpowiednio się kompiluje. Jeśli już teraz pali Ci się jakaś czerwona lampka albo coś jest niezrozumiałe to oczywiście pisz w odpowiedzi na ten mailing :)

Obsesja rzeczownikowa

Znamy się już co nieco, więc pozwól, że podzielę się z Tobą, jak wyglądał jeden, z moich typowych dni:

Budzik -> Łóżko -> Winda -> Żabka -> Słońce -> Rower -> Piwnica -> Praca -> Kawka -> Dom -> Schody -> Winda -> Kurs programowania -> itd...

Chciałbym widzieć Twoją reakcję, kiedy to czytasz :) Z pewnością nie często słyszysz opowieść w takiej formie. Czy jesteś w stanie powiedzieć dokładnie co i kiedy robiłem?

Zastosowałem tutaj niestety powtarzane jak mantra na wielu kursach, czy też na studiach "szukajcie rzeczowników". Mnie tak uczyli i Ciebie pewnie też. Tak uczą przez lata, a jednak branża IT idzie do przodu. 5 lat to już często prehistoria. Co mówili prowadzący? W skrócie: Czytasz, podkreślasz rzeczowniki, zamykasz je w kwadraciki. Potem robisz odpowiednie strzałeczki między nimi i model gotowy! To wszystko doprawione jeszcze notacją niezrozumiałego UMLa. Każdy mniej więcej tak zaczynał, ja też (czuję misję, żeby właśnie zmienić ten status quo).

Niestety na początku wpajano nam te złe nawyki, które teraz ciężko porzucić. Nie tak będzie na tym mailingu. Dzisiaj zaczniemy poznawać metodę, która zmieniła programistyczne życie moje i wielu innych praktyków DDD! EventStorming nie raz wywrócił do góry nogami założenia projektów za miliony EURO — jak mówi największy ekspert w Polsce — Mariusz Gil.

Tabelka i strzałeczki. Czy to jest właśnie legendarny model? Model danych... być może. Model domenowy, o który chodzi w DDD, skupiony na zachowaniach i zdarzeniach — z pewnością NIE! To nie rzeczowniki budują rozumienie. Wszystkie je trzeba osadzić w odpowiednim kontekście, o którym rozważaliśmy ostatnio. Podkreślmy to jeszcze raz. NIE ZACZYNASZ PROJEKTOWANIA SYSTEMU OD MODELU DANYCH.

Jak od każdej reguły jest też wyjątek (jeśli robisz CRUD). Ale zazwyczaj modelujesz jakiś proces biznesowy - za to Ci płacą. Więc powtórzę jeszcze raz (nawet jak scrollujesz maila, to mam nadzieję, że tutaj się zatrzymasz): NIE ZACZYNASZ PROJEKTOWANIA SYSTEMU OD MODELU DANYCH.

Jeśli tak zrobisz, to z pewnością powstanie jedne wielki model i nie będzie w nim wydzielonych kontekstów. Takie coś jest do wszystkiego i do niczego zarazem. NIE ZACZYNASZ PROJEKTOWANIA SYSTEMU OD MODELU DANYCH. To chyba najważniejsze zdanie tego tekstu. Teraz możesz je kontemplować już do końca :)

Mógłbyś teraz zapytać: ale Mateusz, skoro tak nie robić — no to jak żyć? Czas posłuchać Mistrza Yody i pójść za jego radą: "You must unlearn what you have learned". Skoro tak, i chcesz się oduczyć swoich złych nawyków, to odpowiedź jest już w Twoim zasięgu, czytaj dalej :)

Na emigracji, poza Królestwo Rzeczowników

To, że znajdziemy powiązania i relacje między obiektami np. Programista — (1 do wielu) - Praca, nie znaczy, że zrobimy z tego spójną historię modelująca przepływ procesu biznesowego. Dodatkowo brak wiedzy domenowej nie pozwoli nam tutaj uniknąć błędów. W przypadku mojego dnia "ekspert" wiedziałby, że nie piję nigdy Kawy i ktoś tutaj strzelił gafę. Akurat wtedy w pracy zajmowałem się implementacją publikowania zdarzeń na Kafke :) Wyjdźmy teraz poza granice Królestwa Rzeczowników (ang. The Kingdom of Nouns) Przejdźmy na kolejny level poszukiwania bardziej naturalnej dla człowieka formy.

Teraz opowiem Ci mój dzień jeszcze raz, korzystając ze wzbogaconego słownika:

Niestety, budzik nie zadzwonił. Wstałem z łóżka za późno. W windzie byłem już po kilkunastu minutach. Po wyjściu drogę przecięła mi jakaś mała żabka. Słońce grzało tak mocno, że rower tym razem zostawiłem w piwnicy i dojechałem do pracy. Po powrocie do domu wszedłem po schodach, ponieważ winda nie działała. Siadłem do prowadzenia kursu programowania (największego w Polsce, który organizowałem).

, jak to teraz wygląda?
Z takiej wiedzy można rozpocząć już pracę nad jakimś modelem. Oczywiście pozostaje wiele pytań i niejasności.
Musimy wiedzieć, jaki jest cel modelu. Np. wyznaczenie środka transportu / oszacowanie kosztu / optymalizacja wstawania.
Pozwoli nam to widzieć daną rzeczywistość w odpowiednim kontekście i odrzucić to, co nie ma totalnie znaczenia dla rozwiązywanego przez nas problemu.
Pamiętasz poprzedniego maila? Modelując turystyczną mapę metra w Tokyo, nie zajmujesz się wysokościami terenu.

Jednowątkowość ludzkiego języka

Niestety sam opis nie wystarczy. Musimy mieć podstawę do głębszej eksploracji i zadawania pytań. Dla mózgu człowieka o wiele bardziej przystępne są formy graficzne.

Parafrazując wyjaśnienie tego zagadnienia, które słyszałem od jak zawsze fenomenalnego Sława Sobótki (jak dla mnie największy autorytet w Polskiej społeczności DDD): Mózg człowieka działa tak, że tekst / mowę parsujemy sekwencyjnie — jednowątkowo. Słowo po słowie. Z drugiej strony-patrząc na obrazy interpretujemy to, co widzimy równolegle. Na raz dociera do nas wiele komunikatów i kojarzymy je z tym, co spotkaliśmy już wcześniej. Da się zobaczyć rzeczy i pewne powiązania, których nie da rady usłyszeć czy przeczytać.

No dobra! W myśl tej idei ludzie biznesu niestety często proponują coś takiego: "Ja na tych waszych schematach, UMLach nic nie widzę". I będzie to prawda. "Zróbcie mi w takim razie projekty ekranów i będę wiedział, czy zamodelowaliście to właśnie tak jak ma być!". No właśnie... nasz model powinien być możliwy do zweryfikowania przez prawdziwych ekspertów w dziedzinie. Jeśli dostarczysz im coś bardzo technicznego, przesiąknięte skomplikowaną notacją-to być może otrzymasz nawet odpowiedź potwierdzającą, która nie będzie wiele warta

Google to tylko dwa ekrany

Patrząc tylko na sam interfejs użytkownika, jak opiszesz działanie Google? Przykładowo:

• Ekran #1 - Wpisujemy w polu tekstowym, to co chcemy znaleźć.
• Ekran #2 - Wyświetlamy wyniki wyszukiwania.

Widzisz już chyba, jak wielka złożoność systemu została tutaj pominięta? Tak na marginesie: Spotkałem się nawet z wycenami po ekranach... Powiedzmy, że jak zawsze — wszystko w odpowiednim kontekście może mieć zastosowanie. Do prostego CRUDa — gdzie robisz "przeglądarkę” do bazy danych i stosujesz podejście "encja na twarz i pchasz” - to ekrany są wystarczające. Taki model ma posłużyć programiście do tego, żeby wiedział co i jak zaprogramować. Jeśli tak jest, to możesz siadać do kodu. Zazwyczaj jednak Ekran-Driven-Development nie kończy się dobrze. Niestety często połykamy właśnie ten haczyk w myśl zasady "10 godzin kodowania może mi zaoszczędzić 5 minut planowania" i od razu lecimy do klawiatury. Napieprzamy spacje i taby niczym Hardkorowy Kodsu. A potem? Zmieniamy projekt i kto inny musi to utrzymywać :) Profesjonalizm, czy idea Software Craftsmanship, a także samo DDD każe do tego podejść inaczej.

Nie oceniaj książki po okładce

Na przykładzie Google dostrzegasz, że do poprawnego zrozumienia działania biznesu ważniejsze jest to, co "siedzi pod spodem". Wszystko, co musi się wydarzyć, abyś Ty mógł po prostu wpisać szukaną frazę i zobaczyć wynik. Od razu z rękawa mogę wyrzucić kilka rodzajów tego typu zdarzeń: Zindeksowano strone / Dodano opinie / Zmieniono opinie / Oznaczono miejsce na mapie.

Nie pomogą nam też tutaj sławne historyjki użytkownika. User Stories to też dalej tylko tekst-wstęp do dyskusji. To nie są wymagania do projektu! To jest formatowanie tekstu. Podsumowanie tego rozważania zobacz w wystąpieniu wspomnianego Sławka Sobótki Model jest wszystkim czego potrzebujesz od 47:30. Na temat ilustrowania i jak może ono przydać się w testowaniu poczytasz też w moim wpisie TUTAJ.

Zdarzenia, zdarzenia i jeszcze raz zdarzenia

Czym są te zdarzenia, których przykłady podałem powyżej? Zdarzenie traktujmy, jako istotny moment (zazwyczaj zmiana stanu) dla modelowanego procesu, opisany w czasie przeszłym.

Jeśli odkryjesz zdarzenia takie jak Złożono zamówienie, czy Wysłano zamówienie jest prawdopodobne, że istnieje taka encja jak Zamówienie. W Twoich projektach, wykorzystując metody DDD, to właśnie w tą stronę będziesz prowadził wnioskowanie. Od zachowań do bytów osadzonych w kontekście, a nie odwrotnie. Następnie odkryjesz więcej przez zadawanie typowych pytań odnośnie do zdarzeń. Czy składanie zamówienia a dostarczanie go to nie dwa różne konteksty? Może to dwie encje? Czy sprzedawca i dostawca patrzą na kupowany przez Ciebie produkt (np. laptop) z tej samej perspektywy? Co interesuje każdego z nich? Zastanów się i możesz podzielić się swoimi przemyśleniami pisząc do mnie :)

Od karteczek na ścianie do implementacji

Taka metoda, nazywana EventStorming pomaga w modelowaniu procesów i jak wszystko wymaga wielu godzin praktyki. Poniżej możesz zobaczyć, co z tego wychodzi. Jest to kawałek Event Stormingu, jaki przeprowadziłem z mentorowanym przeze mnie zespołem podczas kursu programowania.

Czy z połączonych kwadracików TURNIEJ <- (wiele do wielu) -> ZAWODNIK wiedziałbyś, że zaraz po zapisach następuje losowanie par turniejowych? Takie modelowanie wymaga, aby na sali była osoba, która może znać odpowiedzi na pojawiające się pytania. Powinieneś np. zapytać: "Czy zawsze się tak dzieje"? Odpowiedzią będzie: "No nie, to zależy od typu turnieju — na niektóre pary są znane z góry, a innych są losowane". To pozwoli Ci naprawdę na dogłębną analizę i zrozumienie domeny! Prawdopodobnie nie brałeś udziału w profesjonalnych turniejach futbolu stołowego i nie wiesz, na czym polega kategoria DYP — Draw Your Partner. Choć teraz się pewnie domyślasz :) Dzięki EventStormingowi właśnie coś podobnego możesz odkryć i w Twoim projekcie! My mieliśmy tzw. eksperta domenowego na pokładzie, czyli Panią Prezes Wrocławskiego Klubu Piłki Stołowej. Tak na marginesie - sam też kiedyś trochę trenowałem ten sport :)

Jeśli chcesz zobaczyć implementację niektórych zdarzeń (zaznaczonych na zielono na powyższym screenie), to jest ona dostępna TUTAJ. Ale spokojnie-krok po kroku dojdziemy też do tego. Każde z rozwiązanych zadań praktycznych tego mailingu będzie Cię do tego przybliżać.

Znasz popularny ostatnio Gambit Królowej? W takim razie możesz też spojrzeć na moją implementację silnika szachów z wykorzystaniem zdarzeń. ZNAJDZIESZ JĄ NA GITHUBIE

Coś takiego jest też realizacją podejścia "screaming architecture". Projekt krzyczy do Ciebie i pokazuje, co jest w nim zamodelowane. Patrząc na zdarzenia takie jak Szach-mat (ang. Checkmate) wiesz od razu, że chodzi o grę w szachy. :) Gdyby pojawiły się tutaj tylko klasy takie jak Pionek czy Plansza. Czy bez wczytywania się w kod, można jednoznacznie powiedzieć, że to nie jest gra w Warcaby czy Chińczyka?

To jest Twój czas!

Wykorzystaj go dobrze. Samo czytanie tych wiadomości nie przyniesie rezultatów, jeśli nie będziesz robił zadań. Kafka czy Kawka teraz na chwilę na bok. Do tej pierwszej jeszcze wrócimy :)

Znasz film Karate Kid? Pamiętasz zadania, jakie Mistrz Miyagi dawał Danielowi na początek treningu karate? Malowanie płotu, woskowanie samochodu... Zasada była tylko jedna: Daniel musiał wykonywać jego ćwiczenia bez zastrzeżeń. Nawet ruchy, które wykonywał woskując samochód przydały się później w prawdziwej walce :) Oczywiście, jeśli chcesz lepiej zrozumieć, po co jest dane ćwiczenie, czy cokolwiek innego — to pytaj w odpowiedzi na tego maila :)

Ale ja i osoby, które uczyłem tych metod, mogą Cię już zapewnić: TO DZIAŁA! A może masz już doświadczenie z EventStormingiem i to zadanie będzie dla Ciebie za proste? Daj mi wtedy znać w odpowiedzi :)

ZADANIE #2 - Zgubiony pantofelek (część 1/2)

Dzisiaj mam dla Ciebie bardzo poważne zadanie! Zaginęła ukochana księcia i został po niej tylko pantofelek. Pomóż mu ją odnaleźć!

Co trzeba zrobić?

1. Wejdź na stronę MIRO.COM i załóż bezpłatne konto. Lub jeśli wolisz FIGMA.COM, to wykorzystaj mój autorski szablon, który znajdziesz TUTAJ.
2. Utwórz nowy board.
3. Dodaj do niego dwie pomarańczowe karteczki ze zdarzeniami "ogłoszono bal w pałacu” i "książę odnalazł Kopciuszka".
4. Zostaw dużą przestrzeń między karteczkami.
5. Znajdź kogoś do wspólnego wykonania zadania. Ponieważ nie jest to jakaś specjalistyczna domena, a bajkę zna niemal każdy, to zaproś do wspólnej zabawy swojego partnera / żonę / kolegę, czy nawet teściową. Zapewniam Cię, że już tutaj spotkasz się z sytuacjami jak na prawdziwym EventStormingu. Wersji tej bajki będzie kilka :)
6. Spróbuj dodać zdarzenia, wszystko, co musiało wydarzyć się między nimi dwoma. Możesz też cofnąć się bardziej, czy rozwinąć historię dalej, jeśli uznasz to za przydatne.
7. Upewnij się, że Kopciuszek i książę żyli dłuuuugo i szczęśliwie.
8. Po skończeniu zadania wyślij mi publiczny link do swojego boarda i czekaj na dalsze instrukcje.

Dlaczego właśnie to? Mistrz Miyagi nie udzieliłby odpowiedzi. Więc ja tutaj powołam się na innego mistrza, jakim jest Alberto Brandolini — autor EventStormingu. Cwiczenie to rekomenduje właśnie on sam, jako wprowadzenie i zapoznanie się z tą metodą. Przeprowadzałem ją na organizowanych przeze mnie warsztatach i sprawdzało się to świetnie :) To też dobra metoda jako ice breaker i rozluźnienie dla zebranych w pokoju lub przed monitorami osób.

Jeśli o warsztatach mowa. Może chcesz wziąć w nich udział? Wybrane osoby, które odpowiedzą na to zadanie do 30 września 2023, zaproszę właśnie do udziału w warsztatach z EventStormingu i Event Modelingu (data do ustalenia)! Nie obejdzie się też oczywiście bez kodowania :)

Jestem tutaj dla Ciebie

To zadanie ma dwie części. Czekam na Twoje rozwiązanie, a wtedy napiszę Ci, co dalej. Jeśli coś będzie niejasne podczas Twojego treningu, też pytaj śmiało.

Howgh! 😊

Mateusz Nowak | NaKodach.pl

PS. Zacząć się sezon wesel. Sam niedługo się wybieram do kolegi. Masz już jakieś zaproszenie? Albo planujesz nawet właśnie swój ślub? Jeśli tak, to EventStorming może Ci pomóc też w zorganizowaniu tego ważnego dnia! TUTAJ znajdziesz artykuł na taki temat.