CQRS Event Sourcing: Validate UserName uniqueness

Myślę, że jeszcze nie masz zmiany nastawienia do ewentualnej spójności i natury pozyskiwania zdarzeń. Miałem ten sam problem. W szczególności odmówiłem przyjęcia, że powinieneś zaufać poleceniom klienta, które na twoim przykładzie mówią "Złóż to zamówienie z rabatem 10%" bez potwierdzenia domeny, że rabat powinien iść do przodu. Jedną z rzeczy, które naprawdę trafiły do mnie, było coś, co sam Udi powiedział do mnie (Sprawdź komentarze zaakceptowanej odpowiedzi).

W zasadzie zdałem sobie sprawę, że nie ma powodu, aby nie ufać klientowi; wszystko po stronie odczytu zostało wyprodukowane z modelu domeny, więc nie ma powodu, aby nie przyjmować poleceń. Cokolwiek w czytanej stronie, co mówi, że klient kwalifikuje się do Rabatu, zostało tam umieszczone przez domenę.

BTW: w wymaganiu, jeśli wprowadzona nazwa użytkownika jest już zajęta, strona powinna pokazać komunikat o błędzie "Sorry, the user name XXX is not available" dla odwiedzającego. Nie jest dopuszczalne wyświetlanie wiadomości, powiedzmy, "tworzymy Twoje konto, proszę czekać, wyślemy Ci wynik rejestracji pocztą e-mail później", do odwiedzającego.

Jeśli zamierzasz przyjąć event sourcing i ewentualną spójność, musisz zaakceptować, że czasami nie będzie możliwe wyświetlanie komunikatów o błędach natychmiast po wysłaniu polecenia. Z unikalnym przykładem nazwy użytkownika szanse na to są tak małe (biorąc pod uwagę, że sprawdzasz przeczytaną stronę przed wysłaniem polecenie) nie warto martwić się o zbyt wiele, ale kolejne powiadomienie musiałoby być wysłane do tego scenariusza, a może poprosić ich o inną nazwę Użytkownika przy następnym logowaniu. Wspaniałą rzeczą w tych scenariuszach jest to, że sprawia, że myślisz o wartości biznesowej i o tym, co jest naprawdę ważne.

Aktualizacja: Październik 2015

Chciałem tylko dodać, że w rzeczywistości, gdy chodzi o publiczne strony internetowe-wskazanie, że e-mail jest już zajęty jest właściwie przeciwko najlepszym praktykom bezpieczeństwa. Zamiast tego, Rejestracja powinna wyglądać na pomyślne poinformowanie użytkownika o wysłaniu weryfikacyjnej wiadomości e-mail, ale w przypadku, gdy istnieje nazwa użytkownika, e-mail powinien poinformować go o tym i poprosić o zalogowanie się lub zresetowanie hasła. Chociaż działa to tylko podczas używania adresów e-mail jako nazwy użytkownika, co moim zdaniem jest wskazane z tego powodu.

Nie ma nic złego w tworzeniu od razu spójnych modeli odczytu (np. Nie w rozproszonej sieci), które są aktualizowane w tej samej transakcji co polecenie.

Uzyskanie spójności modeli odczytu w rozproszonej sieci pomaga w skalowaniu modelu odczytu dla ciężkich systemów odczytu. Ale nie ma nic do powiedzenia, że nie możesz mieć specyficznego dla domeny modelu odczytu, który jest natychmiast spójny.

Od razu spójny model odczytu jest używany tylko do sprawdzanie i odbieranie danych przed wydaniem polecenia (tak naprawdę jest to usługa dla polecenia), nigdy nie należy go używać do bezpośredniego wyświetlania odczytywanych danych użytkownikowi(np. z żądania GET web lub podobnego). Użyj ostatecznie consitent, skalowalne modele odczytu do tego.

Podobnie jak wiele innych podczas implementacji systemu opartego na event sourced napotkaliśmy problem unikalności.

Na początku byłem zwolennikiem umożliwienia klientowi dostępu do strony zapytania przed wysłaniem polecenia, aby dowiedzieć się, czy nazwa użytkownika jest unikalna, czy nie. Ale potem zobaczyłem, że posiadanie back-endu, który ma zerową walidację unikalności, jest złym pomysłem. Po co w ogóle egzekwować cokolwiek, skoro można opublikować polecenie, które uszkodziłoby system ? Back-end powinien sprawdzać wszystkie / align = "left" /

Stworzyliśmy index po stronie polecenia. Na przykład, w prostym przypadku nazwy użytkownika, która musi być unikalna, wystarczy utworzyć UserIndex z polem nazwa użytkownika. Teraz strona poleceń może sprawdzić, czy nazwa użytkownika jest już w systemie, czy nie. Po wykonaniu polecenia można bezpiecznie zapisać nową nazwę użytkownika w indeksie.

Coś takiego może również działać na problem z rabatem zamówienia.

The zaletą jest to, że Twój back-end poleceń poprawnie sprawdza wszystkie dane wejściowe, dzięki czemu nie można przechowywać niespójnych danych.

Minusem może być to, że potrzebujesz dodatkowego zapytania dla każdego ograniczenia wyjątkowości i wymuszasz dodatkową złożoność.

Myślę, że w takich przypadkach możemy użyć mechanizmu jak "advisory lock with expiration".

Przykładowe wykonanie:

• Sprawdź, czy nazwa użytkownika istnieje lub nie w docelowym spójnym modelu odczytu
• Jeśli nie istnieje; używając redis-couchbase, takiego jak keyvalue storage lub cache; spróbuj wcisnąć nazwę użytkownika jako pole klucza z pewnym wygaśnięciem.
• If successful; then raise userRegisteredEvent.
• Jeśli nazwa użytkownika istnieje w modelu read lub pamięci podręcznej, poinformuj użytkownika, że nazwa użytkownika została zajęta.

Nawet ty możesz użyć bazy danych sql; wstawić nazwę użytkownika jako klucz główny jakiejś tabeli blokad; a następnie zaplanowane zadanie może obsłużyć wygasanie.

Czy rozważałeś użycie "działającej" pamięci podręcznej jako rodzaj RSVP? Trudno to wyjaśnić, ponieważ działa to trochę w cyklu, ale zasadniczo, gdy nowa nazwa użytkownika jest "potwierdzona" (to znaczy, polecenie zostało wydane, aby ją utworzyć), umieszczasz nazwę użytkownika w pamięci podręcznej z krótkim terminem wygaśnięcia (wystarczająco długo, aby uwzględnić kolejne żądanie przechodzące przez kolejkę i denormalizowane do modelu odczytu). Jeśli jest to jedna instancja usługi, to w pamięci pewnie by zadziałało, w przeciwnym razie scentralizuj ją za pomocą Redis lub coś.

Następnie, gdy następny użytkownik wypełnia formularz (zakładając, że istnieje front end), asynchronicznie sprawdzasz model odczytu pod kątem dostępności nazwy użytkownika i ostrzegasz użytkownika, jeśli jest już zajęty. Po przesłaniu polecenia, sprawdzasz bufor (nie Model odczytu) w celu zweryfikowania żądania przed zaakceptowaniem polecenia( przed zwróceniem 202); jeśli nazwa jest w buforze, nie Akceptuj polecenia, jeśli nie, dodaj ją do bufora; jeśli dodanie nie powiedzie się (zduplikuj klucz, ponieważ jakiś inny proces Cię do niego uprzedził), a następnie przyjmij nazwę-następnie odpowiednio zareaguj na klienta. Między tymi dwoma rzeczami, nie sądzę, że będzie wiele okazji do kolizji.

Jeśli nie ma front endu, możesz pominąć szukanie asynchroniczne lub przynajmniej poprosić API o podanie punktu końcowego, aby go wyszukać. Naprawdę nie powinieneś pozwalać klientowi mówić bezpośrednio do modelu poleceń, a umieszczenie API przed nim pozwoliłoby ci na niech API będzie pośrednikiem między komendą a hostami read.

O wyjątkowości zaimplementowałem:

• Pierwsze polecenie typu "StartUserRegistration". UserAggregate zostanie utworzony bez względu na to, czy użytkownik jest unikalny, czy nie, ale ze statusem rejestracji wymaganym.

• Na "UserRegistrationStarted" zostanie wysłana asynchroniczna wiadomość do bezpaństwowej usługi "UsernamesRegistry". byłoby coś w stylu "RegisterName".

• Serwis będzie próbował zaktualizować (bez zapytań, "powiedz nie pytaj") tabelę, która obejmowałoby unikalne ograniczenie.

• Jeśli się powiedzie, usługa odpowie inną wiadomością (asynchronicznie), z rodzajem autoryzacji "UsernameRegistration", stwierdzając, że nazwa użytkownika została pomyślnie zarejestrowana. Możesz dołączyć kilka żądań, aby śledzić w przypadku jednoczesnej kompetencji (mało prawdopodobne).

• Emitent powyższej wiadomości ma teraz autoryzację, że nazwa została zarejestrowana przez siebie, więc teraz może bezpiecznie oznaczyć agregat UserRegistration jako sukcesy W przeciwnym razie Zaznacz jako odrzucone.

:

• Takie podejście nie wymaga zapytań.

• Rejestracja użytkownika byłaby zawsze tworzona bez walidacji.

• Proces potwierdzania wymagałby dwóch asynchronicznych wiadomości i jednej wstawki db. Tabela nie jest częścią modelu odczytu, ale usługi.

• Na koniec jedno polecenie asynchroniczne, aby potwierdzić, że użytkownik jest poprawny.

• W tym punkt, denormalizer może zareagować na Zdarzenie UserRegistrationConfirmed i utworzyć model odczytu dla użytkownika.