PictOgr – mój CQRS -3-

Command Query Responsibility Segregation – 3 –

CQRS
Niniejszy wpis dotyczy implementacji Event Sourcingu w moim CQRSie. Jest to kolejna szyna wykorzystywana na różne sposoby.

Można np. zachować (jeżeli system cały system oparty jest o CQRS/ES) stan aplikacji w poszczególnych etapach jej życia. Zapis stanów musi odbyć sie np. w bazie danych. Nie mniej jednak pozwoli to na przedstawienie historii od A do Z cyklu życia

Dokładnie po wykonaniu każdej z komend jak zmienia się model aplikacji. Zdarzenia wyzalane są z komend.

Zastosowanie zdarzeń pozwoli na powiadamianie różnych obszarów aplikacji o zmianie stanu aplikacji.

 

Zdarzenia i szyna zdarzeń

IEvent interfejs bazowy dla wszystkich zapytań, klas implementująca zostanie przekazana do zarejestrowanych obserwatorów.

 

IEventHandler – podobnie jak poprzednio (IQueryHandler), implementując ten kontrakt tworzymy kod przetwarzający logikę.

@event – jak wiadomo event to słowo kluczowe języka c#, jednak można to obejść wykorzystując znak małpki ‚@’, nakazujemy kompilatorowi, iż nie chcemy skorzystać ze słowa kluczowego event, a jedynie użyć jako nazway zmiennej.

 

IEventBus, kontrakt dla szyny zdarzeń, w tym przypadku klasa implementująca musi zawierać trzy metody:

  • Register – służy do rejestrowania obserwatora zdarzenia,
  • UnRegister – analogicznie tą metodą wyrzucamy obserwatora zdarzeń,
  • Publish – dzięki tej metodzie przekazujemy wszystkim słuchaczom zdarzenie.

 

EventBus to implementacja interfejsu IEventBus.

Lista eventList = new Dictionary<Type, List<object>>();

Jest to lista zdarzeń, do której zostaną, która to dopiero będzie powiązana z listą obserwatorów.CQRS

[IEvent => { IEventHandler, IEventHandler, IEventHandler, etc.}]

Metoda Register, sprawdza czy IEventHanlder jest już zarejestrowany, jeśli nie to dodaje do listy.

UnRegister, sprawdza czy IEventHandler jest na liście, jeżeli jest to usuwa.

Publish – iteruje po wszystkich IEvent, oraz podległych IEventHandlerach i publikuje zdarzenie.

 

Testy

Klasę testu zaczynamy od ustawienia (TearUp) podstawowych/najczęściej używanych w testach obiektów jak container, fakeEvent, eventFakeInvoke, fakeEventHandler.

Na końcu konstruktora tworzymy fake dla metody Handler, tak by pobierać event jaki jest do niej przekazywany jako parametr, tak na zaś do assertów.

Pierwszy teścik taki symboliczny, czy faktycznie EventBus to EventBus prosto z AutoFac-a.

Jak się powodzi to lecimy dalej.

A tutaj to sprawdzimy czy szyna zdarzeń po publikacji (Publish) oszukanego zdarzenia (fakeEvent) rzuci wyjąteczkiem TypeUnloadedException.

A no bo POWINNA!

Teraz to już powinno być dobrze, pierwsza publikacja i odebranie prawidłowego IEvent, część kodu zawarta w TearUp, tak że tutaj prościutko.

Odebrany IEvent musi być taki sam jak ten publikowany!

A tutaj sobie sprawdzimy jak działa Register i UnRegister.

Zarejestrowany IEventHandler i wyrejestrowany po publikacji wali wyjątkiem TypeUnloadedException!

Ostatni tłusty teścik rejestruje aż 100 IEventHandlerów, po czym publikuje do nich fakeEvent-a.

Tym samym powinno dojść 100 oszukanych eventów zapisanych do listy.

Na końcu to już wyrejestrowanie handlerków, i sprawdzenie czy faktycznie te 100 eventów jest oszukanych (fakeEvent).

 

Na koniecCQRS

Co prawda więcej w poście kodu niż treści, ale myślę, że zrozumiały tekst.

W kolejnym poście połączymy ES z CQRS, oraz dodamy zapowiadane na ten post walidatory.

 

 

Dziękuję za wytrwałość i zachęcam do komentowania.

 

 

Jest to post przygotowany na potrzeby konkursu „Daj Się Poznać 2017” organizowanym przez Macieja Aniserowicza.