Nie jestem do końca pewien, dlaczego kiedykolwiek nawadniałeś swoje Agregaty z samego Sklepu Eventowego.
Ponieważ „wydarzenia” to księgi rekordów.
Jeśli prognozowanie zmian w bazach danych „do odczytu” jest tak łatwe, dlaczego nie zawsze projektować zmiany w bazie danych „do zapisu”, których schemat idealnie pasuje do modelu domeny? Byłaby to skutecznie baza danych migawek.
Tak; czasem użyteczną optymalizacją wydajności jest użycie buforowanej kopii stanu agregacji, a nie generowanie tego stanu od nowa za każdym razem. Pamiętaj: pierwszą zasadą optymalizacji wydajności jest „nie”. Zwiększa to złożoność rozwiązania i wolisz go unikać, dopóki nie uzyskasz przekonującej motywacji biznesowej.
W takim przypadku, czy Event Store jest przydatny tylko podczas przebudowy bazy danych „write” w wyniku zmian schematu? A może brakuje mi czegoś większego?
Brakuje czegoś większego.
Po pierwsze, jeśli zastanawiasz się nad rozwiązaniem pochodzącym od zdarzenia, dzieje się tak dlatego, że oczekujesz wartości w zachowaniu historii tego, co się wydarzyło, to znaczy, że chcesz wprowadzać nieniszczące zmiany .
Dlatego w ogóle piszemy do sklepu z wydarzeniami.
W szczególności oznacza to, że każdą zmianę należy zapisać w magazynie zdarzeń.
Rywalizujący pisarze mogą potencjalnie albo zniszczyć nawzajem swoje zapisy, albo doprowadzić system do niezamierzonego stanu, jeśli nie znają się nawzajem. Tak więc zwykłym podejściem, gdy potrzebujesz spójności, jest skierowanie swoich zapisów do określonej pozycji w czasopiśmie (analogicznie do warunkowego PUT w interfejsie HTTP). Niepowodzenie zapisu informuje pisarza, że ich bieżące rozumienie dziennika nie jest zsynchronizowane i że powinni się zregenerować.
Powrót do znanej dobrej pozycji, a następnie odtworzenie wszelkich dodatkowych zdarzeń, ponieważ ten punkt jest powszechną strategią odzyskiwania. Ta znana dobra pozycja może być kopią tego, co znajduje się w lokalnej pamięci podręcznej lub reprezentacją w sklepie z migawkami.
Na szczęśliwej ścieżce możesz zachować migawkę agregatu w pamięci; wystarczy skontaktować się z zewnętrznym sklepem, gdy nie ma dostępnej kopii lokalnej.
Co więcej, nie musisz być całkowicie pochłonięty, jeśli masz dostęp do księgi rekordów.
Tak więc zwykłym podejściem ( jeśli używa się repozytorium migawek) jest utrzymywanie go asynchronicznie . W ten sposób, jeśli musisz odzyskać, możesz to zrobić bez ponownego ładowania i odtwarzania całej historii agregatu.
W wielu przypadkach ta złożoność nie jest interesująca, ponieważ drobnoziarniste agregaty o określonym czasie życia zwykle nie gromadzą wystarczającej liczby zdarzeń, aby korzyści przewyższyły koszty utrzymania pamięci podręcznej migawki.
Ale gdy jest to właściwe narzędzie do rozwiązania problemu, wczytanie nieaktualnej reprezentacji agregatu do modelu zapisu, a następnie zaktualizowanie go o dodatkowe zdarzenia, jest całkowicie rozsądnym rozwiązaniem.