Siema Mireczki, chciałbym into cqrs + es przy użyciu spring cloud stream + kafka trochę już o tym poczytałem ale tylko to zrodziło więcej pytań mianowicie załóżmy, że mamy zwykłą rejestrację użytkownika plus jego późniejszą autentykacje, czyli założenie konta + credentali (login/haslo) + wysłanie linka z potwierdzeniem i po aktywacji konta i podaniu login/hasło wygenerowanie jwt.
Logiczne wydaje się to rozbicie na 3 serwisy
- user serivce - auth service - email service
No i teraz tak gdzie idzie POST signupa ? pod /users czy /auth, tak czy siak trzeba odwiedzić kilka serwisów dla przykładu dajmy narazie POST pod /auth który generuje natępujący chain CreateCredentialCommand -> aggregat(AuthService odbiera to zapisuje login/haslo generuje idka tej parze) -> CredentialCreateEvent -> aggregat(UserService) -> CreateUserCommand -> aggregat(UserService robi profil uzytkownika) -> UserCreatedEvent -> aggregat(UserService generuje wiadomosc email) -> SendEmailCommand -> aggregat(EmailService wysyla email) -> EmailSendedEvent -> powiadominie użytkownika na UI.
1. Czy to jest poprawne rozumowanie ?
2. Czy może skoro stworzenie credentiali i konta użytkownika jest mocno ze sobą powiązane zrobić to klasycznie czyli POST /user generuje CreateUserCommand -> aggregat(UserService synchronicznie robi POST /auth gdzie są tworzone credentiale ) -> UserCreatedEvent ... itd ?
3. Jak powiadamiać użytkownika o wynikach operacji ? -a. generować np request id wstrzykiwac go do commands-events oraz zapisywać go w Map a jak wroci brać z mapy emmitera przypisanego do danego request i wysyłać do klienta info -b. stworzyć notyfication service który będzie statelessowy i zrobic coś jak w punkcie a tylko na userid ? -c. coś innego ?
4. Co w przypadku jak coś się #!$%@? np baza danych dla emialservice padła ?
Kupione w ciemno za jakieś grosze rok temu, psiknięte dwa razy. Nie mogę znieść tego zapachu, więc robię #rozdajo #perfumy nie wiem tylko czy ten syf można określić mianem perfum
Przesyłkę InPost opłaca wygrywający.
Losowanie dzisiaj o 21.
Udziału nie biorą: zielonki, użytkownicy z tagów pato mma gal
Logiczne wydaje się to rozbicie na 3 serwisy
- user serivce
- auth service
- email service
No i teraz tak gdzie idzie POST signupa ? pod /users czy /auth, tak czy siak trzeba odwiedzić kilka serwisów dla przykładu dajmy narazie POST pod /auth który generuje natępujący chain CreateCredentialCommand -> aggregat(AuthService odbiera to zapisuje login/haslo generuje idka tej parze) -> CredentialCreateEvent -> aggregat(UserService) -> CreateUserCommand -> aggregat(UserService robi profil uzytkownika) -> UserCreatedEvent -> aggregat(UserService generuje wiadomosc email) -> SendEmailCommand -> aggregat(EmailService wysyla email) -> EmailSendedEvent -> powiadominie użytkownika na UI.
1. Czy to jest poprawne rozumowanie ?
2. Czy może skoro stworzenie credentiali i konta użytkownika jest mocno ze sobą powiązane zrobić to klasycznie czyli POST /user generuje CreateUserCommand -> aggregat(UserService synchronicznie robi POST /auth gdzie są tworzone credentiale ) -> UserCreatedEvent ... itd ?
3. Jak powiadamiać użytkownika o wynikach operacji ?
-a. generować np request id wstrzykiwac go do commands-events oraz zapisywać go w Map a jak wroci brać z mapy emmitera przypisanego do danego request i wysyłać do klienta info
-b. stworzyć notyfication service który będzie statelessowy i zrobic coś jak w punkcie a tylko na userid ?
-c. coś innego ?
4. Co w przypadku jak coś się #!$%@? np baza danych dla emialservice padła ?
#java #spring #cqrs #microservices #cloud
wołam też @interface bo ogarnięty chłop ( ͡° ͜ʖ ͡°)
Komentarz usunięty przez autora