Jak radzić sobie z efektami ubocznymi w CRQS podczas odtwarzania zdarzeń?

Mówi się, że w CQRS łatwo jest naprawić błąd, wystarczy ponownie wdrożyć, a następnie odtworzyć zdarzenia.

Ale co jeśli jedno ze zdarzeń spowoduje, że zewnętrzny system, który nie jest w twojej kontroli, „wyśle ​​przedmiot” do klienta, jeśli po prostu odtworzysz zdarzenia, przedmiot zostanie wysłany dwukrotnie.

Jak to rozwiązujesz?

Konieczne jest wyraźne oddzielenie zdarzeń modyfikujących stan modelu odczytu od zdarzeń (potencjalnie) modyfikujących stan systemów zewnętrznych. Upewnij się, że nie masz żadnych „mieszanych zdarzeń” modyfikujących oba stany razem. W ten sposób możesz odtwarzać zdarzenia w określonym „trybie odtwarzania”, w którym zdarzenia dla systemu zewnętrznego nie są ponownie uruchamiane. W tym trybie „symulujesz” również zdarzenia, które zostały pierwotnie zainicjowane przez system zewnętrzny (teraz pobierasz je z kolejki odtwarzania).

Nie zapomnij, że krok ponownego wdrożenia oznacza zresetowanie stanu odczytanego modelu do wcześniejszego momentu. Prawdopodobnie nie jest to nic, co możesz zrobić (lub zrobić) dla stanu systemów zewnętrznych.

Z artykułu Martina Fowlera poświęconego zaopatrzeniu w wydarzenia :

Podstawową ideą Event Sourcing jest zapewnienie, że każda zmiana stanu aplikacji jest rejestrowana w obiekcie zdarzenia oraz że te obiekty zdarzeń są same przechowywane w kolejności, w jakiej zostały zastosowane przez ten sam okres istnienia, co sam stan aplikacji.

Kiedy więc musisz przywrócić stan systemu do określonego momentu, odtwarzasz stan przechowywany , a nie procedury obsługi zdarzeń, aż do tego momentu.

Biorąc to pod uwagę, jeśli pracujesz tylko z danymi stanu, nie powinno to mieć żadnego wpływu na system zewnętrzny. O ile nie masz wyzwalaczy lub obserwatorów w swoim sklepie zdarzeń, w takim przypadku powinieneś je wyłączyć na czas przywracania. Ponieważ mówisz, że nie masz kontroli nad systemem zewnętrznym, nie powinieneś podejmować żadnych prób przywrócenia jego stanu za pomocą odsłoniętego interfejsu API, ponieważ nie wiesz, jakie skutki uboczne może mieć w tym systemie. Jeśli przywrócenie powoduje, że system znajduje się w stanie pośrednim (np. Z powodu nieudanych operacji w systemie zewnętrznym), nie powinno to wchodzić w zakres odpowiedzialności za odtworzenie zdarzenia.

Ale co jeśli jedno ze zdarzeń spowoduje, że zewnętrzny system, który nie jest w twojej kontroli, „wyśle ​​przedmiot” do klienta, jeśli po prostu odtworzysz zdarzenia, przedmiot zostanie wysłany dwukrotnie.

Aby wybrać konkretny przykład, zastanówmy się, jak może działać „przynajmniej raz” podejście do skutków ubocznych.

State currentState = State.InitialState
for(Event e : events) {
    currentState = currentState.apply(e)
}
for(SideEffect s : currentState.querySideEffects()) {
    performSideEffect(s)

Model domeny śledzi więc, co należy zrobić; ale pozostawia faktyczne działanie aplikacji

W kontekście uruchamiania polecenia podstawowy pomysł wygląda tak samo. Rzeczywiste skutki uboczne występują poza transakcją aktualizującą model.

Testy jednostkowe dla twojego modelu mogą wyglądać mniej więcej tak

{
    // Given
    State currentState = State.InitialState

    // When
    Events events = List.of(OrderPlaced)

    // Then
    List.of(SendEmail) === currentState.applyAll(events).querySideEffects()
}

{
    // Given
    State currentState = State.InitialState

    // When
    Events events = List.of(OrderPlaced, EmailSent)

    // Then
    List.EMPTY === currentState.applyAll(events).querySideEffects()
}

Głównymi punktami są tutaj

• Aktualizacja modelu nie powoduje skutków ubocznych; rzeczywiste skutki uboczne występują poza transakcją aktualizującą model.
• Wydarzenie opisujące wynik działania niepożądanego musi wrócić.