@mzagozda Dziękuję bardzo! Cieszę się, że się podobało 🤩 Bardzo dobre pytanie.
Zacznijmy od tego, że sam Event Sourcing jest wzorcem, który co prawda o tym mówi, jak przechowywać dane, a w zasadzie nie tyle jak co w jakiej formie - konkretnie zdarzeń. Jednak sam w sobie nie mówi gdzie 1/
Zacznijmy od tego, że sam Event Sourcing jest wzorcem, który co prawda o tym mówi, jak przechowywać dane, a w zasadzie nie tyle jak co w jakiej formie - konkretnie zdarzeń. Jednak sam w sobie nie mówi gdzie 1/
@mzagozda Zatem moglibyśmy przechowywać te zdarzenia równie dobrze w pliku tekstowym, binarnym, excelu, xmlu, json, czy też już bardziej rzeczywiście w bazie danych. No i tutaj w zależności od tego jaka jest charakterystyka naszego miejsca przechowywania takie mamy też możliwości 2/
@mzagozda Jeżeli korzystamy z jakiegoś rozproszonej bazy danych to może to być faktycznie utrudnione. Większość z nich ma możliwość tylko "symulowania" takiej weryfikacji (np. DynamoDB aws.amazon.com/blogs/database…). Zwykle jest to przy symulowane poprzez algorytmy rozwiązywania konfliktów /3
@mzagozda Przykładem może być np. 2-Phase commit (martin.kleppmann.com/2016/03/07/qco…). Zwykle najprostszą unikalności w strumieniach zdarzeń jest nadanie klucza strumienia (czyli naszego rekordu) tak aby zawierał w sobie wartość, którą chcemy mieć unikalność /4
@mzagozda Np. jeśli mamy fakturę, która musi mieć unikalny numer, albo użytkownika, który ma mieć unikalny email to wziąć jako klucze odpowiednio numer faktury i email. Zarówno systemy rozproszone jak i relacyjne potrafią zachowywać unikalność swoich kluczy /5
@mzagozda No i wracając do Event Sourcing, @marten_lib i baz relacyjnych. Jeśli używamy do przechowywania bazę (np. @postgresql) relacyjną to ułatwiamy sobie zachowanie unikalności. Marten potrafi zarówno obsłużyć wspomiane już klucze stringowe (nie tylko guid): martendb.io/documentation/… /6
@mzagozda @marten_lib @PostgreSQL Sama tabela eventów nie wspiera nakładania na niej kluczy dodatkowych (poza domyślnymi) out of the box - spowolniłoby to dodawanie. Możemy jednak powiedzieć Marten, żeby robił Snapshot ostatniego (najświeższego stanu agregatu). Taki snapshot będzie zapisany jako dokument /7
@mzagozda @marten_lib @PostgreSQL Na takim dokumencie możemy zakładać już dowolne indeksy, klucze itd. W tym właśnie unikalne: martendb.io/documentation/…. Dzięki temu jak wykonamy operację biznesową to w trakcie zapisu zdarzenia zostanie też zapisany stan agregatu i na nim zostanie sprawdzona unikalność /8
@mzagozda @marten_lib @PostgreSQL W przykładach, których prezentowałem można znaleźć to dla takiej reguły: siedzenie może mieć maksymalnie jedną aktywną (nieanulowaną) transakcję. Aby tego dokonać wystarczy kazać Marten robić snapshot github.com/oskardudycz/Ev… oraz... /9
@mzagozda @marten_lib @PostgreSQL ...oraz ustawić regułę unikalności na nim github.com/oskardudycz/Ev… I to tyle - reszta już się będzie działa pod spodem. Czy to jest odpowiedź na Twoje pytanie? 😅 Trochę się rozpisałem, także szacun jak dotrwałeś do tego momentu @mzagozda
10/10
10/10
