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. Mniej kodu do utrzymania, mniej potencjalnych błędów, a problem biznesowy rozwiązany.