Czytam o pozyskiwaniu wydarzeń i mam pytanie dotyczące wytrwałości.
Nadal mogę mieć DB ze wszystkimi podmiotami, prawda? A może zdarzenia powinny być odtwarzane przy każdym uruchomieniu aplikacji, aby uzyskać najnowszą wersję każdego elementu w pamięci? Wydaje się to marnotrawstwem w większych systemach (jak w przypadku dużej ilości danych)?
Chodzi o to, że w razie potrzeby mogę odtworzyć zdarzenia, aby zapełnić magazyn danych? (lub analizuj dane)
Odpowiedzi:
Najkorzystniej skorzystasz z pozyskiwania zdarzeń, gdy zdecydujesz się również zmienić architekturę systemu. Dążenie do architektury w stylu CQRS w połączeniu z DDD przyniesie prawdziwe korzyści z pozyskiwania zdarzeń, przynajmniej moim zdaniem.
Zbudowanie magazynu zdarzeń, który zachowuje się dobrze w dużych systemach, nie jest łatwym zadaniem. Odtwarzanie wszystkich danych może być rzeczywiście kosztowne, zależy w dużej mierze od ilości danych, które należy odtworzyć. Są jednak techniki, które mogą ci w tym pomóc, jedną z nich jest koncepcja migawki. Powtórka jest wykonywana tylko od pewnego momentu. Korzyści, jakie sklep ze zdarzeniami wnosi do twojego systemu są nieocenione. Dzięki temu, że wszystko, co wydarzyło się w twoim systemie, jest możliwe do odtworzenia, wszystkie dane w każdej chwili to świetna rzecz. Pomyśl o analizie, o odtwarzaniu błędów, o statystykach.
Istnieje wiele świetnych sklepów z wydarzeniami, ostatni został właśnie wydany wczoraj Event Store i wygląda na naprawdę dobry.
Tradycyjna baza danych może być przechowywana dla części kwerendy twojego systemu, aby zbudować DTO z żądanymi danymi. Ta baza danych może być zorganizowana i zoptymalizowana z uwzględnieniem potrzeb zapytań twojej aplikacji i klientów.
Napisałem szczegółowy artykuł o tym, jakie są korzyści i jak naprawdę wygląda architektura CQRS w połączeniu z pozyskiwaniem zdarzeń. Możesz to sprawdzić w CQRS, zdarzeniach domenowych i przeglądzie DDD .
W przypadku Event Sourcing głównym pytaniem jest „jaka jest twoja książka rekordów”.
Jeśli twoja księga rekordów jest Twoim strumieniem wydarzeń, nie będziesz mieć problemów. Jeśli twoja księga rekordów jest twoim „modelem bytu”, problemy zaczną się dziać wszędzie. Częścią tego jest to, że możesz powiedzieć „jeśli zgubiłem mój model bytu, czy mógłbym go odbudować ze strumienia zdarzeń”. Jeśli masz pozytywną odpowiedź na to pytanie, Twój dziennik zdarzeń jest Twoją książką.
Należy również pamiętać, że większość osób korzystających z pozyskiwania zdarzeń korzysta z modelu odczytu. Ten model służy do tworzenia zapytań o dane. Jest to jednak bardziej prawdopodobne, że będzie wyglądać jak model 1nf niż model encji 3nf. Odtwarzają tylko zdarzenia, aby przywrócić stany agregatów i ustalić, czy zapisy powinny być dozwolone.
Nadal mogę mieć DB ze wszystkimi podmiotami, prawda? A może zdarzenia powinny być odtwarzane przy każdym uruchomieniu aplikacji, aby uzyskać najnowszą wersję każdego elementu w pamięci?
Odpowiedź zależy od wymagań aplikacji. Widziałem, jak robi się to na dwa sposoby.
Jeden niezwykle udany pakiet oprogramowania dla małych firm księgowych odczytuje dziennik CQRS przy każdym uruchomieniu. Surowa ilość danych była stosunkowo niewielka, więc czas uruchamiania był krótszy niż minuta, nawet na wolniejszych komputerach. Robili CQRS od ponad dekady, zanim praktyka stała się popularna. Wiedzieli, że wpadli na coś dobrego, kiedy zdali sobie sprawę, że mogą ciągle aktualizować dane swoich klientów bez problemów z większymi systemami.
W systemach z większymi ilościami danych i / lub systemach opartych na funkcjonalności RDBMS do implementacji strony zapytania masz bazę danych dla „bieżącego widoku” danych pochodzących ze zdarzeń (możesz mieć nawet wiele takich widoków). Zaletą tego podejścia jest to, że pozwala budować stronę zapytania przy użyciu znanych technologii.