Cześć

Miałem trudności z napisaniem kodu ukazującego popularne błędy przy tworzeniu architektury/implementacji systemów opartych na zdarzeniach. Nawet zastanawiałem się nad zapłaceniem jakiemuś juniorowi za napisanie takiego czegoś. Potrzebowałem takiego kodu jako punktu wyjścia dla mojego nowego warsztatu pt. "Event Sourcing na produkcji". Teraz znalazłem rozwiązanie i zacząłem korzystać z ChatGPT. Kod, który generuje, idealnie pasować do takich potrzeb!

Żarty na bok. Narzędzie jest imponujące i mocno wierzę, że jest obecnie niezbędne, ponieważ przyspiesza prace związane z kodem szablonowym.

Pamiętam czasy, kiedy nie było StackOverflow, a mimo to potrafiliśmy pisać kod; również nie zostaliśmy zwolnieni (jak przewidywano 10 lat temu) z powodu powstania SO. Czy nasza praca się zmieniła? Oczywiście. Czy jest lepsza czy gorsza? Jest inna.

I to jest wspaniałe; musimy tylko dostosować się i znaleźć dobry sposób na korzystanie z tego narzędzia. Traktuję to jako szansę skupienia się na tym, co ważne.

Praca z ChatGPT przypomniała mi pair programming ze zdolnym klepaczem, ale słabym programistą. Osiągniesz przyzwoite wyniki, jeśli dobrze go poprowadzisz, ale nie zrobi dla ciebie architektury. To narzędzie przypomina mi fabułę filmu Memento. Facet, który ma stare wspomnienia, pamięta co wydarzyło się minutę temu, ale zapomina o tym, o czym rozmawialiśmy 10 minut temu i nie jest w stanie być zbyt kreatywny z powodu tej amnezji.

Zobacz bieżący wynik w repozytorium: https://github.com/oskardudycz/event-sourcing-on-prod-workshop/.

Co ciekawe, ChatGPT4  jest dużo lepszy niż 3.5.

Po dłuższej dyskusji udało mi się go namówić na napisanie poprawnej implementacji Event Store, którą zamierzam wykorzystać w nowym pet project: https://github.com/oskardudycz/emmett. Czy chcesz zobaczyć jak wyglądała ta dyskusja?

Kto by pomyślał, że kuny to takie słodziaki co? Nigdy mało fotek z nimi!

Ale ja nie o tym, ale o unikalności w Event Sourcing.

Powiedzmy, że chcielibyśmy wymusić unikalność adresu e-mail użytkownika. Teoretycznie można by zapytać model odczytu, przechowującym dane wszystkich użytkowników, i sprawdzić, czy użytkownik z wybranym adresem e-mail już istnieje. Bułka z masłem? Brzmi tak, ale tak nie jest. Takie podejście da ci fałszywe gwarancje. W międzyczasie, pomiędzy otrzymaniem wyniku, uruchomieniem logiki biznesowej i zapisaniem informacji o nowym użytkowniku, ktoś mógł dodać użytkownika z tym samym adresem e-mail. Poleganie na rezultacie odczytu nigdy nie jest wiarygodne; powinniśmy mówić, a nie pytać. W takim przypadku domagajmy się adresu e-mail użytkownika i albo odnieść sukces, albo ponieść porażkę.

Walidacja unikalności to jedna z tych rzeczy, które wydają się proste, ale nie zawsze są łatwe. Z mojego doświadczenia wynika, że wymaganie unikalości często wskazuje na to, że nasz biznes przynosi nam rozwiązanie zamiast problemu. Powinniśmy upewnić się, że to, co mamy dostarczyć, to rzeczywiste wymaganie, i zadać wystarczająco dużo pytań "dlaczego", zanim się zobowiążemy to zrobić.

Jednak czasami musimy wybrać rzeczy, o które chcemy walczyć. Wszystkich bitew nie wygramy. Czaem musimy po prostu coś zrobić.

W Marten staramy się pokazać pragmatyczne oblicze Event Sourcing i zaakceptować, że to, czy coś jest najlepszą praktyką, czy antywzorcem, zależy od kontekstu. Napisałem o pragmatycznym triku, który może uprościć egzekwowanie unikalnych ograniczeń w Event Sourcing, korzystając z Marten. 

Przeczytaj: https://event-driven.io/pl/unique_constraint_in_marten_event_store/

Zerknij też do najnowszego Architecture Weekly:https://www.architecture-weekly.com/p/architecture-weekly-120-27th-march

Zachęcam do dołączenia do płatnej wersji i społeczności na Discord. Sporo fajnych ludzi i fajnych treści (np. webinary).

Spokojnego tygodnia!