Ad. 1. Chodzi Ci o broker wiadomości? Kafka lub RabbitMQ
Chodzi mi o to aby mógł odtworzyć stan obiektów na podstawie zdarzeń, które zaszły w systemie. Jeżeli więc użytkownik:
- Zarejestruje się w systemie i poda swój adres e-mail. Niech to będzie adres X
- Później zmieni swój adres e-mail z X na Y
- Później zmieni swój adres e-mail z Y na Z
To ja:
- Zapiszę gdzieś informację o tym, że doszło do zarejestrowania użytkownika z adresem e-mail X
- Zapiszę gdzieś informację o tym, że użytkownik zmienił adres e-mail z X na Y
- Zapiszę gdzieś informację o tym, że użytkownik zmienił adres e-mail z Y na Z
- Jak trzeba będzie ustalić jaki jest obecny adres e-mail użytkownika to przeczytam wszystkie powyższe zdarzenia i będę wiedział, że aktualny adres e-mail to Z.
Poczytałem trochę, że Kafka może sprostać tym oczekiwaniom ponieważ w Kafce można zapisać sekwencje zdarzeń i ją później przeczytać od początku do końca. Jednak spotkałem się też z krytyką takiego zastosowania i w sumie nie wiem jak to jest (informacje krytyczne mogą nie być już aktualne).
Co do Rabbita to mam trochę większe wątpliwości czy to się do tego nadaje. Nie używałem tego ale kojarzy mi się to bardziej z przesyłaniem komunikatów bez gwarancji, że zostanie zachowana kolejność ich dostarczania no i nie wiem czy można sobie przeczytać od tak cała historie komunikatów od samego początku czy bardziej działa to na zasadzie "masz dostęp do komunikatu, którego jeszcze nie odebrałeś a nie do tych, które kiedyś zostały już dostarczone".
Ad. 2. Nie rozumiem pytania
Załóżmy hipotetycznie, że technologie RabbitMQ, Kafka i Axon spełniają wymagania i można to wykorzystać do Event Sourcingu. Jeżeli np. w projektach tworzonych za pomocą języka Java dominuje technologia Axon (np. w 8 na 10 Javowych projektach korzysta się z Axona, w 1 na 10 z Rabbita i w 1 na 10 z Kafki) to odpowiedź na moje pytanie brzmi "Axon jest najpopularniejsza technologią stosowana do Event Sourcingu w Javowych projektach". Gdyby to RabbitMQ był najbardziej popularną technologią w Javowych projektach to wtedy odpowiedź na moje pytanie brzmi "RabbitMQ jest najpopularniejsza technologią stosowana do Event Sourcingu w Javowych projektach". Sam RabbitMQ nie jest wtedy technologią ściśle powiązaną z Javą tylko technologią, z której mogą korzystać również programiści innych języków no ale jeżeli akurat Javowcy tego zazwyczaj używają to taka byłaby odpowiedź.
Ad. 3. Synchronizacja stanu bazy po offline to strasznie skomplikiwany problem. W przypadku ogolnym nierozwiązywalny
No właśnie odnoszę wrażenie, że przy zastosowaniu Event Sourcingu problem mógłby się znacznie uprościć (tak mi się przynajmniej wydaje na chwilę obecną :))
a czy na pewno jest Ci to potrzebne?
Jeszcze nie wiem :) Generalnie to chciałem poszerzyć nieco horyzonty więc chętnie wypróbuje :)
Ta opcja 3 brzmi bardzo źle, bo oznacza że można by bardzo łatwo zaburzyć spójność danych i generalnie narobić cudów w systemie, skoro pozwalasz na "modyfikowanie historii", szczególnie z poziomu jakiejś aplikacji klienckiej. Nie wiem co ten system ma robić, ale mocno bym się nad tym zastanowił.
Rozumiem Twoje obawy. Jednak jeżeli chodzi o aplikacje kliencką to raczej chciałbym to zorganizować w ten sposób żeby taka aplikacja mogła synchronizować zdarzenia z serwerem tylko wtedy kiedy użytkownik ma odpowiednie uprawnienia do tego. Zakładam tutaj, że albo użytkownikiem nie będzie przypadkowa osoba albo sytuacje, w której użytkownik nie będzie miał możliwości synchronizowania zdarzeń, które mogą mieć wpływ na innych użytkowników.