Zapytania o domeny w CQRS
Testujemy CQRS . Mamy sytuację walidacji, w której CustomerService (usługa domeny) musi wiedzieć, czy klient istnieje, czy nie. Klienci są unikalni pod względem adresu e-mail. Nasze repozytorium klientów (ogólne repozytorium) ma tylko Get (id) I Add (customer). W jaki sposób CustomerService powinien dowiedzieć się, czy klient istnieje?
4 answers
Spójrz na ten wpis na blogu: Set based validation in the CQRS Architecture .
Porusza ten właśnie problem. To skomplikowany problem, z którym trzeba sobie poradzić w CQR. To, co Bjarte sugeruje, to odpytywanie bazy danych raportów o istniejących adresach e-mail klientów i wydanie polecenia kompensującego (takiego jak CustomerEmailAddressIsNotUniqueCompensatingCommand) z powrotem do modelu domeny, jeśli adres e-mail został znaleziony. Następnie można odpalić odpowiednie zdarzenia, które mogą zawierać UndoCustomerCreationEvent.
Przeczytaj komentarze na powyższy post na blogu dla alternatywnych pomysłów.
Adam D. sugeruje w komentarzu, że Walidacja jest problemem domeny. Dzięki temu możesz przechowywać ReservedEmailAddresses w usłudze, która ułatwia tworzenie klientów i jest wzbogacana o Wydarzenia w Twoim sklepie eventowym.
Nie jestem pewien, czy istnieje łatwe rozwiązanie tego problemu, które wydaje się całkowicie czyste. Daj mi znać, co wymyśliłeś! Powodzenia!Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-08-12 11:15:37
Ten problem nie musi być tak złożony:
- Sprawdź swój magazyn raportów pod kątem unikalności klienta przed wysłaniem polecenia UpdateCustomer.
- Dodaj ograniczenie do DB dla unikalności adresu e-mail. Podczas wykonywania polecenia obsłuż wyjątek i Wyślij powiadomienie do Użytkownika za pomocą kanału odpowiedzi. (nigdy nie uruchamia zdarzeń zaktualizowanych przez Klienta do sklepu raportującego.
Użyj bazy danych do tego, co jest dobre i nie daj się zawiesić na Ograniczenia ORM.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-04 11:36:28
This post by Udi Dahan http://www.udidahan.com/2009/12/09/clarified-cqrs / zawiera następujący akapit:
"ponadto nie powinniśmy potrzebować dostępu do magazynu zapytań, aby przetwarzać polecenia – każdy potrzebny stan powinien być zarządzany przez komponent autonomiczny – to część znaczenia autonomii."
Wierzę, że Udi zasugerował po prostu dodanie unikalnego ograniczenia do bazy danych.
Ale jeśli nie masz ochoty tego robić, na podstawie powyższego stwierdzenia, Sugerowałbym po prostu dodanie metody" ByEmail " do repozytorium i zakończenie z nią - ale potem znowu Udi miałby chyba lepszą propozycję..
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-28 11:52:33
Mam nadzieję, że nie jest za późno...ale mieliśmy do czynienia z podobną sytuacją w naszym projekcie, faktycznie przechwycić executor polecenia i dołączyć go z zestawem reguł utworzonych dla tego polecenia, które z kolei wykorzystuje zapytanie do pobrania danych.
Tak więc w tym przypadku możemy mieć klasę o nazwie CustomerEmailMustBeUniqueRule, która jest pobierana przez RuleEngine, gdy polecenie "RegisterCustomerCommand" ma być wykonane przez RegisterCustomerCommandExecutor. Ta klasa reguł ma odpowiedzialność za zapytanie do bazy danych, aby znaleźć, czy identyfikator e-mail istnieje i zatrzymać wykonanie, podnosząc nieprawidłowy znacznik...
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-09-03 03:31:30