Jak robicie, gdy musicie zrobić walidacje w komendach czy coś istnieje? Wstrzykujecie read model do komendy czy może jakiś inny serwis?
Drugie pytanie jak zasilacie read model macie bazke do tego czy z event stora zaciągacie wszystkie eventy przy starcie serwisu? Bo na ten moment mam tak, że event stora mam cosmos db, a read model mam in memory I zaciagam dane przy starcie serwisu.
0
1
Walidacja:
- Dekorator na handlerach zapięty globalnie (MediatR), walidacja komendy za pomocą FluentValidation, handlery zwracają Either<Result,Error> więc jest gdzie się wpiąć żeby zwrocić błąd, można też rzucać wyjątek.
- Komenda powinna zawierać wszystkie dane potrzebne do jej wykonania. Podczas wykonania komendy odczyt jest zawsze z event stora który jest in-sync. Do tego dodaje się optimistic concurrency w postaci pola version na agregacie. Tak żeby 2 zapisy nie nadpisały siebie.
- Read model - można job'em lub eventami przez Kafkę, jeżeli trzymasz eventy w sql'owej bazie. Na CosmosDB się nie znam, ale słyszałem że to podobne do MonogDB, tam można trzymać agregaty jako dokumenty, i mieć z głowy zabawę z ES.
- Read model in-memory: wada jest taka że gdy będziesz potrzebował zrestartować komponent który trzyma dane in-memory (np. upgrade Redisa, lub zwykły restart usługi) to zaciągniesz całą bazę do pamięci. Baza (lub tutaj twoja aplikacja) może tego nie wytrzymać jeżeli będzie tam poważna ilość danych. To co ja bym trzymał w pamięci to cache na najczęściej używane dane i dane słownikowe, jeżeli to ma sens w danym use-case'ie.
Paczaj słynne wypociny Grega Younga:
Na sieci jest mnóstwo materiałów na ten temat. Generalnie jak aplikacje się wykładają to zazwyczaj na tym że ludzie olewają read-model i robią restore z eventów w pamięci, i to zabija wydajność.
Trzeba też dobrze znać swoją DB i wiedzieć jak zachowuje się pod względem wydajności. Taka Cassandra może być niespójna jak z ringu wypadną node'y, trzeba wiedzieć jak dobrać quorum itp. Podobnie praca z MongoDB jest inna, tam można by trzymać agregat z jednoczesnym snapshotem stanu obecnego i listą eventów i wszystko było by transakcyjne.
<prywatne-opinia>
CosmosDB (swoją drogą niedawno była wtopa security) to jakieś dziwactwo (document store zbudowany na key-value store), które miało być wszystkim a wyszło G.