Grafika została złożona ze zrzutów ekranu zrobionych podczas rozgrywki w grę Heroes of Might and Magic III.
Z życia na kodach
W zakładce O mnie możemy poznać się lepiej. Jednak pozwól, iż podzielę się z Tobą jeszcze, 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?
Przykład jak DALLE-3 wygenerował obraz do tego opisu, dzięki AI.
(Kliknij obrazek, aby powiększyć)
Obsesja rzeczownikowa
Zastosowałem tutaj niestety powtarzane jak mantra na wielu kursach, czy też na studiach “szukajcie rzeczowników” + tabelki i strzałeczki. Podobnie możesz się czuć dostając schemat bazy danych, kiedy chcesz się dowiedzieć do robi dany system.
Mnie tak uczyli i Ciebie pewnie też. Tak wykładają przez lata, a jednak branża IT idzie do przodu. 5 lat to już często prehistoria. Co mówili prowadzący (mam nadzieję, iż u Ciebie może jednak było inaczej)? W skrócie: Czytasz, podkreślasz rzeczowniki, zamykasz je w kwadraciki. Potem robisz odpowiednie strzałeczki między nimi (szukasz relacji) i model gotowy! To wszystko doprawione jeszcze notacją niezrozumiałego UMLa. Każdy mniej więcej tak zaczynał. Ja też, i teraz 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 blogu i mailingu. Dzisiaj wprowadzę Cię w 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, obrazujący problem do rozwiązania, o który chodzi w DDD, skupiony na zachowaniach i zdarzeniach — z pewnością NIE! To nie rzeczowniki budują rozumienie. Wszystkie je trzeba osadzić we właściwym kontekście, o którym rozważaliśmy ostatnio TUTAJ. Powiedzmy to bezpośrednio: NIE ZACZYNASZ PROJEKTOWANIA SYSTEMU OD MODELU DANYCH.
Jak od każdej reguły jest też wyjątek (jeśli robisz CRUD w stylu “encja na twarz i pchasz”). Ale zwykle modelujesz jakiś proces biznesowy - za to Ci płacą, a to drugie już zastąpią “skończoną liczbą stażystów” albo rozwiązaniem pokroju ChatGPT. Więc powtórzę jeszcze raz (nawet jak scrollujesz , to mam nadzieję, iż tutaj się zatrzymasz): NIE ZACZYNASZ PROJEKTOWANIA SYSTEMU OD MODELU DANYCH.
Bounded Contexty wokół nas
Jeśli jednak nie posłuchasz tej rady, to najprawdopodobniej w Twoim projekcie powstanie jeden wielki model i nie będzie w nim wydzielonych kontekstów. Takie coś jest do wszystkiego i do niczego zarazem. Modelując reprezentację rzeczywistości musimy się skupiać na problemie, aby wybrać adekwatny model, który pozwoli nam rozwiązać dany problem. Znasz już przykład mapy z poprzedniego wpisu o kontekstach.
Niedawno kupowałem jedno mieszkanie, a różnych rzutów i rysunków było o wiele więcej! Dotyczyły one dokładnie tego samego rzeczywistego lokum, jednak każdy plan był przeznaczony dla innych osób (np. hydraulika, elektryka, projektanta, do katalogu developera) i odpowiadał na inne pytania.
Rzut mieszkania z katalogu. Daje mi ogólne pojęcie wymiarów ale nie zobaczysz tutaj np. rozmieszczenia gniazdek elektrycznych czy grubości ścian.
(Kliknij obrazek, aby powiększyć)
Z Bounded Contextami spotykamy się na co dzień, często choćby nie zdając sobie sprawy. Kiedy idziesz z jakimś problemem do lekarza, to zależnie od specjalizacji patrzy na Ciebie pod inymm kątem i interesują go inne badania. Kardiolog spyta Cię o coś zupełnie innego niż psychiatra.
NIE ZACZYNASZ PROJEKTOWANIA SYSTEMU OD MODELU DANYCH. Może jestem jak zdarta płyta, ale to naprawdę ważne i nie tak oczywiste dla wszystkich. To chyba najważniejsze zdanie tego tekstu. Teraz możesz je kontemplować już do końca :)
"Musisz oduczyć się tego, czego się nauczyłeś." ~ Mistrz Yoda w Gwiezdne Wojny: Imperium Kontratakuje
(Kliknij obrazek, aby powiększyć)
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”. Te słowa z mojej ulubionej sceny w sadze Star Wars pozostają zawsze aktualne, i możemy je zastosować do wielu aspektów życia. Jakże trudno jest porzucić stare przyzwyczajenia, które niekoniecznie są dla nas dobre!
Skoro chcesz pójść za radą sędziwego Jedi, i masz zamiar oduczyć się swoich złych programistycznych nawyków, to odpowiedź jest już w Twoim zasięgu, czytaj dalej :) Zmiana myślenia nie będzie jednak łatwa, przejście ze skupienia na tabelkach i danych do zdarzeń i procesów jest niezwykle trudne, ale warte swojej ceny. Dzięki temu projektowany system nie będzie tylko przełożeniem rzeczywistości na relacje i tabele tak jak się wydaje programiście, ale będzie w stanie ewoluować wraz z rozwojem biznesu. W dłuższej perspektywie dostrzeżesz diametralną różnicę.
Na emigracji, poza Królestwo Rzeczowników
To, iż znajdziemy powiązania i relacje między obiektami np. Programista <— (1 do wielu) -> Praca, nie znaczy, iż 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, iż 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, iż 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).
Przykład jak DALLE-3 wygenerował obraz do tego opisu, dzięki AI.
(Kliknij obrazek, aby powiększyć)
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ść we właściwym kontekście i odrzucić to, co nie ma totalnie znaczenia dla rozwiązywanego przez nas problemu. Pamiętasz przykład map z TEGO wpisu? Modelując mapę metra w Tokyo, nie zajmujesz się wysokościami terenu. Chociaż one istnieją, to są poza zakresem Twoich zainteresowań. Podobnie np. badając opływowość kształtu samochodu, nie musimy już wydać pieniędzy na całe gotowe auto. Wystarczy nam model z jakiegoś tworzywa - dokładnie “model, który zamodeluje” nam to jakby zachowywał się w danych warunkach realny samochód.
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 (jeden z największych autorytetów w Polskiej społeczności DDD): Mózg człowieka działa tak, iż 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 prawdą. “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 choćby odpowiedź potwierdzającą, która nie będzie wiele warta. Jednak nie wszystko da się przedstawić dzięki ekranów. To najwięcej się dzieje tam, gdzie użytkownik “nie klika”. “Backendowcy” wiedzą o czym mówię 😎
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.
A potem prezes pyta dlaczego implementacja trwa tak długo. Przecież “to tylko dwa ekrany” :) Widzisz już chyba, jak wielka złożoność systemu została tutaj pominięta? Tak na marginesie: spotkałem się choćby z wycenami po ekranach… Powiedzmy, iż jak zawsze — wszystko we właściwym 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 sugeruje podejść do tego inaczej.
Wykorzystując okazję: szczerze współczuję i bardzo przepraszam programistów, którzy teraz siedzą w bagnie moich pierwszych komercyjnych projektów (z dedykacją dla Pawła). Wtedy myślałem, iż dużo wiem, a teraz już mam świadomość ile jeszcze muszę się nauczyć (zgodnie z efektem Krugera-Dunninga). Jeśli zrobiliście git blame i wyskoczyło tam moje nazwisko - no to czytajcie dalej jak nie popełniać takich 💩 - wtedy zaczynałem od modelu danych i myślałem, iż “robię dobrze”, bo tak mnie nauczono. Jednak “dobrymi chęciami piekło jest wybrukowane” 😈.
Nie oceniaj książki po okładce
Na przykładzie Google dostrzegasz, iż 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, iż 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? Analogicznie jak w przypadku mieszkania. Co interesuje każdego z nich? Zastanów się i możesz podzielić się swoimi przemyśleniami pisząc do mnie albo komentując ten wpis :)
Od karteczek na ścianie do implementacji
Taka metoda, nazywana EventStorming (czy jej ewolucja - EventModeling) 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 (z oczywistych względów ciężko, żebym zdradzał Ci tutaj sekrety komercyjnych projektów). Całość znajdziesz na MIRO board TUTAJ (wraz z rozwinięciem w EventModeling, o którym też możesz poczytać TUTAJ).
Wycinek EventStormingu systemu do obsługi turniejów w piłkarzyki.
(Kliknij obrazek, aby powiększyć)
Czy z połączonych kwadracików TURNIEJ <- (wiele do wielu) -> ZAWODNIK wiedziałbyś, iż 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 na 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 (sam też czasem gram w turniejach). Więcej o piłkarzykach na wyższym poziomie seniority znajdziesz TUTAJ.
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 szczegółów implementacyjnych wraz z rozwojem NaKodach.pl. Każde z rozwiązanych zadań praktycznych tego mailinguhttps://nakodach.pl/lista-mailingowa/ będzie Cię do tego przybliżać.
♟️ Szach-mat CRUDy!
Znasz popularny niedawno serial 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, iż chodzi o grę w szachy. :) Gdyby pojawiły się tutaj tylko klasy takie jak Pionek czy Plansza, albo co gorsza pakiety Controller, Model, Repository… Czy wtedy bez wczytywania się w kod, można jednoznacznie powiedzieć, iż 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żeli 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 czy w końcu pomalowanie całego domu… 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żeli chcesz lepiej zrozumieć, po co jest dane ćwiczenie, czy cokolwiek innego — to pytaj w komentarzach :)
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? Napisz wtedy o swoich doświadczeniach, żeby wzbogacić innych :)
ZADANIE #2 - 👠 Zgubiony pantofelek (część 1/2)
Kopciuszek gubi pantofelek. Masz jakiegoś "eksperta domenowego" od bajek w domu?
(Kliknij obrazek, aby powiększyć)
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ć?
- Wejdź na stronę MIRO.COM i załóż bezpłatne konto. Lub jeżeli wolisz FIGMA.COM, to wykorzystaj mój autorski szablon, który znajdziesz TUTAJ.
- Utwórz nowy board.
- Dodaj do niego dwie pomarańczowe karteczki ze zdarzeniami “ogłoszono bal w pałacu” i “książę odnalazł Kopciuszka”.
- Zostaw dużą przestrzeń między karteczkami.
- 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 choćby teściową. Zapewniam Cię, iż już tutaj spotkasz się z sytuacjami jak na prawdziwym EventStormingu. Wersji tej bajki będzie kilka, tak jak i pytań bez odpowiedzi :)
- 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żeli uznasz to za przydatne.
- Upewnij się, iż Kopciuszek i książę żyli dłuuuugo i szczęśliwie.
- 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. Ćwiczenie 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. Łatwo też znajdziesz kogoś do roli “eksperta domenowego” :)
Jeśli o warsztatach mowa. Może chcesz wziąć w nich udział? Co jakiś czas zaproszenie na takie szkolenie z EventStormingu i Event Modelingu (nie obejdzie się też oczywiście bez kodowania) wysyłam do osób zapisanych na mój MAILING.
Jestem tutaj dla Ciebie
To zadanie ma dwie części. Rozwiązanie możesz mi przesłać na adres mateusz@nakodach.pl, albo podzielić się nim w komentarzu. Wtedy napiszę Ci, co dalej. jeżeli coś będzie niejasne podczas Twojego treningu, też pytaj śmiało.
Ten post jest częścią Mailingu Domain-Driven Design. Jeśli chcesz dostać więcej tego typu treści i mieć ze mną ułatwiony kontakt, to koniecznie zapisz się TUTAJ. Czytam i odpowiadam na wszystkie maile. To czasochłonne zajęcie, ale karma wraca z prędkością światła. Wszelkie luźne myśli też mile widziane albo cokolwiek innego, co Twoje paluszki chcą właśnie wystukać na klawiaturze.
