Event Sourcing - CQRS w użyciu

Event Sourcing  - CQRS w użyciu

No i stało się. Choć chwilkę się zastanawiałem, ale ostatecznie użyłem w nowym projekcie architekturę opartą o EventSourcing. Nawet pomimo tego iż projekt wcale nie jest duży. Pomyślałem, że przy takiej skali projektu jak będzie coś nie tak to łatwo będzie to wywalić i zastąpić standardowym podejściem do trzymania bieżącego stanu w tabelach.

Pierwsze odczucia po kilkunastodniowym kodowaniu to chęć powrotu do standardowego podejścia. Kiedy nachodziły mnie takie myśli wmawiałem sobie, że EventSourcing to po prostu taki inny sposób na trzymanie danych w bazie, i tyle. No bo... co może pójść źle? :)

Myśli takie nachodziły mnie z kilku powodów, ale przewodni to zwiększona ilość czasu na kodowanie. Defacto musisz stworzyć dwa modele. Tak, tak. Bez CQRS tego nie ma jak w prosty sposób ogarnąć. Chyba, że robisz aplikację, która nie zwraca żadnych danych i nic nie wyświetla.

Pierwszy model w części zapisu to tzw. logika biznesowa. Ona jest odpowiedzialna za przetwarzanie komend i generowanie zdarzeń. Drugi model to tzw. Read-Store, czyli część systemu odpowiedzialna za odczyt danych, na przykład do wyświetlania ich w UI czy generowania raportów.

Drugi powód to konieczność tworzenia sporej ilości klas. No bo tak:

Uzbierało się trochę.

Jednak po pewnym czasie zacząłem dostrzegać plusy i to nie małe.

I tu dochodzimy do dwóch plusów, które są (jak dla mnie) potężne w swej prostocie:

Teraz już nawet nie odczuwam, że coś zajmuje mi troszkę więcej czasu. A może już nie zajmuje więcej czasu, bo wszystko mam obcykane? To wcale nie jest takie trudne jak się na początku wydaje. Zobaczymy jak będzie dalej... :)

Komentarze