Domain Model cz4

 Kolejny raz bez kodu, kolejny raz z Cluade-m w roli analityka.

Głównym tematem dziś będą Pivotal Events i bounded contexty.

Na sesji Event Stormingu odkryliśmy trzy tzw. pivotal events. 

Czym jest pivotal event, to nie będzie definicja, bo jej nie znam, wiem tylko tyle, że takie zdarzenie określa, że system wchodzi w nowy kontekst, nowy stan, który jest nieodwracalny. Takie zdarzenie wyznacza granicę kontekstu. Zmienia słownictwo.

Wyjaśnię to zaraz na przykładzie pierwszego kontekstu i pierwszego takiego zdarzenia(pivotal event).

Poruszam się w kontekście maratonu rowerowego.

Pierwsze zdarzenie o którym mowa to 

Przypisano numer startowy

Te zdarzenie zamyka kontekst rejestracji zawodnika. 

W obrębie tego kontekstu każda osoba, która zgłosi chęć uczestnictwa w maratonie staje się jego uczestnikiem, czyli zostaje zarejestrowana w tym wydarzeniu. Oznacza to, że może wybrać dystans na którym pojedzie, musi podać wszystkie dane, które są obowiązkowe, może je dowolnie zmieniać, również dystans.

Jednak w chwili opłacenia startu, zostaje przypisany uczestnikowi numer startowy. Skutkiem czego uczestnik staje się zawodnikiem, czyli godzi się na warunki startu, wyraża chęć uczestnictwa poprzez wniesienie opłaty. W tym momencie zawodnik traci możliwość zmiany dystansu i zmiany danych, które wprowadził. Zyskuje jednak dostęp do nowego kontekstu, kontekstu związanego z generowaniem grup startowych.

Te zdarzenie jest nieodwracalne nie da się przełączyć zawodnika z powrotem na uczestnika. Zawodnik może zrezygnować ze startu,  rezygnacja zawodnika wiąże się z wykreśleniem go z puli zawodników, ale jego numer nie trafia już do wolnych numerów. Jeżeli zawodnik, który zrezygnował postanowi jednak się ponownie zarejestrować i opłacić udział otrzyma nowy numer.

Tak więc te zdarzenie jest pivotalne i wyznacza granicę kontekstu rejestracji.

Kolejne zdarzenie, które wyznacza granicę kontekstu to

Wystartowano zawodników

To zdarzenie kończy kontekst generowania i przygotowania zawodników - grup do startowych. Po tym zdarzeniu zawodnik może już tylko jechać do przodu, nie da się cofnąć startu. Zawodnik może zrezygnować ale wiąże się to z definitywnym zakończeniem zawodów i dyskwalifikacją. Zawodnik może nie ukończyć swojego dystansu, np jedzie na 400 ale przejedzie tylko 100, będzie inaczej traktowany niż ci, którzy jadą 100 km ale reguły tego traktowania są zapisane w tym nowym kontekście, który zaczyna się od zdarzenia Wystartowano zawodników.

Zastanawiałem się nad słownictwem w tym kontekście. W poprzednim uczestnik zmieniał się w zawodnika, tu nie następuje tak spektakularna zmiana. Mamy dalej zawodników ale np grupa nie ma już znaczenie żadnego, sam zawodnik jako osoba, też nie bardziej liczy się czas przejazdu i numer, dystans również. Zawodnik w tym kontekście otrzymuje nowe cechy, które go definiują czyli wspomniany wyżej czas przejazdu i pokonana odległość czyli dystans. Tyle że wcześniej ten dystans to był założeniem deklaracją teraz jest realizacją.

Kolejne ważne zdarzenia, to 

Zakończono przejazdy

Te zdarzenie kończy maraton, jest zamknięciem pomiaru czasu. Jest granicą kontekstu ponieważ po tym zdarzeniu pomiar czasu jest nie możliwy, a wszystkie zarejestrowane czasy stają się historią danej edycji maratonu. Tu należy nadmienić, że jest to maraton 24h. Każdy dystans ma swój limit czasowy, dla przykładu 600 km ma 24h, 300 km 12h kolejne dystanse krócej. Dystanse nie startowały razem, tzn. były wydzielone te, które stratowały w sobotę (maraton był z soboty na niedziele). W sobotę startowały najdłuższe dystanse czyli te, które miały ograniczenie do 24h, kolejne krótsze startowały w niedziele ale tak żeby wszyscy mogli kończyć jednocześnie.

Dzięki temu można było zakończyć maraton dla wszystkich o tej samej porze, o ustalonej godzinie. Czyli zdarzenie zakończono przejazdy też można wrzucić do worka zdarzeń pivotalnych, czyli jak się wydarzy nie można go cofnąć, jest granicą poprzedniego kontekstu, otwiera nowy w którym zawodnik jest rekordem w tabeli wyników a pod uwagę brany jest jego dystans i czas przejazdu i czy przejechał deklarowaną odległość.

Typy zdarzeń 

Claude zatrudniłem jako pomoc w obaleniu tych zdarzeń, to była bitwa na argumenty. Te trzy zdarzenia się obroniły ale okazało się, że mają nie co inny zasięg.

• przypisano numer startowy,
• wystartowano zawodników

Te dwa zdarzenia mają charakter bardziej lokalny, szczególnie pierwsze gdzie zmieniamy słownictwo, uczestnik zmienia się na zawodnika. Jest to bardziej widoczne niż w drugim kontekście gdzie dochodzi nam aspekt czasu. Ale te dwa zdarzenia mają charakter lokalny bo nie odnoszą się do wszystkich, zawodników, do całego systemu. Ich zaistnienie powoduje skutki w systemie ale nie tak spektakularne jak ostatni event czyli Zakończono przejazdy. 

Dlaczego charakter lokalny?

Przypisanie numeru następuje w chwili potwierdzenia wprowadzenia opłaty przez zawodnik, czyli nie każdy zawodnik w jednej chwili wprowadza opłatę. Tak samo nie wszystkie dystanse są wystartowane w o tym samym czasie. Póki nie wystartował dany dystans można się na nie go zapisać. W chwili startu następuje zamknięcie pewnych funkcji ale otwarcie nowych.

Zdarzenie globalne

Zakończono przejazdy - te zdarzenie jest inne jego uruchomienie ma charakter globalny, obejmuje wszystkich zawodników, powoduje naraz zmianę kontekstu dla całego systemu. To zdarzenie zatrzymuje pomiar czasu, ten zawodnik który nie dał rady dojechać do mety albo punktu kontrolnego będzie nie klasyfikowany na swoim dystansie lub zdyskwalifikowany. To będzie określone w tym nowym kontekście poprzez reguły służące do klasyfikacji zawodników.

Podsumowanie

Zastanawiałem się nad istotą tego posta, w poprzednim już nie powstał kod, ale tu tym bardziej kod nie powstanie, bo może wyznaczenie granic i tych ważnych zdarzeń jest dużo bardziej ważne od samego kodzenia. W dzisiejszych czasach można go zlecić sztucznej inteligencji, pytanie czy te same AI może właściwie wyznaczyć granicę kontekstów, odnaleźć takie pivotal events, zrozumieć biznes i domenę?

Po co mi te zdarzenia? Dlaczego są one tak istotne dla procesu?

• oznaczają granicę jednego kontekstu i wyznaczenie drugiego
• zmieniają reguły i słownictwo, poprzez zmianę kontekstu
• są drogowskazami, które informują o nieodwracalności
• zabierają możliwości ale dają inne

Linki:

Conducting the event and insight storming workshop

Domain-Driven Design — EventStorming

Domain model cz3

 Tym razem inne podejście.

Wracamy do agregatu z poprzedniej części. Tyczy się on zdarzenia Zmiana Grupy Startowej. Mamy tam opisane takie reguły jak:

• Grupy startowe muszą być wygenerowane,
• Nie przekroczono terminu zmian grupy,
• Grupa docelowa jest z tego samego dystansu,
• Zawodnik nie zmieniał wcześniej grupy,
• Grupa docelowa musi mieć miejsce.

Określiłem reguły typu "must be" (musi być spełniona) czyli:

• grupy startowe muszą być wygenerowane,
• grupa docelowa musi być z tego samego dystansu

Te dwie reguły są niezmiennikami, po analizie wyszło nam, że nie da się ich pominąć ani zmienić.

Pozostałe reguły nie są już tak "niezmienne", istnieją przypadki o których wspomniałem w poprzedniej części mówiące że można nagiąć te reguły.

Reguły możliwe do pominięcia 

Wracając do sedna, reguła

• grupa docelowa musi mieć miejsce

Według logiki nie można zmienić grupy na taką która nie ma miejsca ale kontekst nagięcia tej reguły jest taki.

Mamy start zawodników mamy dwie grupy:

1. grupa numer1 na 500 km 15 osób
2. grupa numer2 na 500 km 1 osoba

Start grup odbywa się co 15 minut (co jakiś ustalony w regulaminie czas, dla przykładu 15 minut, nie pamiętam ile było w rzeczywistości), w moim przykładzie mam dwie grupy jedna 15 osób druga 1 osoba, pytanie czy ta jedna osoba ma czekać dodatkowe 15 minut? Ze względów organizacyjnych można taką osobę puścić w grupie poprzedniej. Grupy jako takie nie mają wpływu na sam przebieg maratonu, czyli są tylko zbiorami na zawodników, służącymi temu żeby zachować porządek i spełnić tę regułę. Grupie też przypisuje się start o tej samej godzinie.

Tak więc nic nie stoi na przeszkodzie żeby tego jednego zawodnika puścić razem z poprzednią grupą. Oficjalnie będzie występował w swojej grupie ale w chwili startu dwie grupy będą puszczone w jednej chwili.

Tak więc można dojść do wniosku, że jednak nie zostanie naruszona ta reguła. Mało tego ta reguła stanie się niezmiennikiem.

Analiza

W dojściu do tego wniosku pomógł mi Claude który stał się moim "sparing partnerem" i zamiast klepacza kodu stał się "gumową kaczką", która mówi.

Wcześniejsze podejście (poprzedni post) sugerował, że można dodać do kodu złamanie reguły, tudzież politykę, która umożliwiałaby taką sytuacje. Byłem świecie przekonany, że zatrudnię Clauda, któremu wrzucę problem i "wyklepie" mi rozwiązanie, ale podczas dodatkowej analizy, zdałem sobie sprawę, że to nie jest naginanie niezmiennika. To jest zupełnie coś innego co może śmiało być po za systemem, po za domeną.

Dlaczego muszę zawsze dążyć do tego żeby stworzyć kod? 

Może lepiej nie tworzyć kodu, a rozwiązanie. 

W tym przykładzie mam tego jednego zawodnika w grupie i drugą pełną grupę to mógłbym ja jako sędzia trasy w porozumieniu z organizatorami wypuścić takiego człowieka razem z grupą poprzednią. 

Czym jest grupa zawodników dla systemu? Jest zbiorem zawodników i spełnieniem reguły, że wystartować możemy maksymalnie grupę składającą się z 15 osób. Mamy na listach, czy w intrenecie wydrukowaną informacje, że start grupy jest o danej godzinie, dla systemu pomiaru czasu nie ma to żadnego znaczenia. Więc sędzia trasy, który wypuszcza zawodników wykorzysta interfejs aplikacji żeby wypuścić w tym samym momencie dwie grupy jedną 15 osobową i jedną 1 osobową.

Czyli pozostanie to w sferze rozwiązania poza systemowego, a to oznacza, że niezmiennik został obroniony. A samo rozwiązanie jest za pomocą "interfejsu białkowego".

Podsumowanie

 Nie wprowadziłem dodatkowego kodu i komplikacji do rozwiązania. Dzięki szerszemu spojrzeniu i zatrudnieniu Clauda w roli jakby drugiego analityka, który może spojrzeć z boku na problem, udało się nie pisać kodu. Wprowadzić rozwiązanie wykorzystując istniejące  możliwości.