best event sourcing db strategy

Rozwiązaniem jest struktura db, w której tworzy się tylko jedną tabelę generyczną i zapisuje zdarzenia jako szeregowany ciąg znaków do jednej kolumny

Jest to zdecydowanie najlepsze podejście, ponieważ odtwarzanie wydarzeń jest prostsze. Teraz moje dwa centy na event sourcing: jest to świetny wzór, ale powinieneś być ostrożny, ponieważ nie wszystko jest tak proste, jak się wydaje. W systemie, nad którym pracowałem zapisaliśmy strumień zdarzeń na agregat, ale nadal mieliśmy zestaw normalizowanych tabel, ponieważ po prostu mogliśmy nie akceptujemy, że aby uzyskać najnowszy stan obiektu, musielibyśmy uruchomić wszystkie zdarzenia (migawki Pomagają, ale nie są idealnym rozwiązaniem). Tak więc tak, pozyskiwanie zdarzeń jest dobrym wzorcem, daje pełne wersjonowanie podmiotów i pełny dziennik audytu, i powinien być używany tylko do tego, a nie jako zamiennik zestawu znormalizowanych tabel, ale to tylko moje dwa centy.

Myślę, że najlepszym rozwiązaniem będzie iść z #2. A nawet możesz zapisać swój aktualny stan wraz z powiązanym zdarzeniem w tym samym czasie, jeśli używasz bazy transakcyjnej, takiej jak mysql.

Jeśli Twoja troska o #1 jest o wersjonowaniu/aktualizacji zdarzeń; następnie zadeklaruj nową klasę dla każdej nowej zmiany. Nie bądź zbyt leniwy; lub obsesja z ponownego użycia. Poinformuj subskrybentów o zmianach; daj im wydarzenie wersja.

Jeśli Twoje koncerty dla #1 chodzi o coś w rodzaju zapytań / interpretacji zdarzeń; później możesz łatwo przenieść swoje zdarzenia do nosqldb lub eventstore w dowolnym momencie (z oryginalnego db).

Również; wzorzec, którego używam dla eventsourcing lib jest coś takiego:

public interface IUserCreated : IEventModel
{

}

public class UserCreatedV1 : IUserCreated
{
    public string Email { get; set; }
    public string Password { get; set; }
}

public class UserCreatedV2 : IUserCreated
{
    // Fullname added to user creation. Wrt issue: OA-143

    public string Email { get; set; }
    public string Password { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

public class EventRecord<T> where T : IEventModel
{
    public string SessionId { get; set; } // Can be set in emitter.
    public string RequestId { get; set; } // Can be set in emitter.
    public DateTime CreatedDate { get; set; } // Can be set in emitter.
    public string EventName { get; set; } // Extract from class or interface name.
    public string EventVersion { get; set; } // Extract from class name
    public T EventModel { get; set; } // Can be set in emitter.
}

public interface IEventModel { }

Tak; uczynić wersjonowanie i uaktualnianie zdarzeń jawnymi; zarówno w domenie, jak i w bazie kodowej. Zaimplementuj obsługę nowych zdarzeń w subskrybentach przed wdrożeniem origin nowych zdarzeń. Oraz; jeżeli nie jest to wymagane, nie zezwalaj na bezpośrednie pochłanianie zdarzeń domen od zewnętrznych subskrybentów; umieść warstwę integracyjną lub coś w tym stylu.

Czytałem o podejściu event-sourcing, które polega na:

1. posiadanie dwóch tabel: zbiorczej i eventowej;

2. Base on you use cases either:

   A. tworzy i rejestruje w tabeli zbiorczej, generując ID, version = 0 oraz typ zdarzenia i tworzy Zdarzenie w tabeli zdarzeń;

   B. pobranie z tabeli zbiorczej, zdarzeń według ID lub typu zdarzenia, zastosowanie przypadków biznesowych ,a następnie zaktualizowanie tabeli zbiorczej (wersja i typ zdarzenia), a następnie utworzenie zdarzenia na zdarzeniu stolik.

Chociaż to podejście aktualizuje niektóre pola w tabeli agregatowej, pozostawia tabelę zdarzeń jako tylko dopisek i poprawia performace, ponieważ masz najnowszą wersję agregatu w tabeli agregatowej.

Wybrałbym #2, a jeśli naprawdę chcesz mieć skuteczny sposób wyszukiwania poprzez typ zdarzenia, po prostu dodałbym indeks do tej kolumny.