Pytanie architektoniczne

Question

W wyniku poprzedniego posta (Architecture: simple CQS) Zastanawiałem się, jak zbudować prosty system, który będzie wystarczająco elastyczny, aby można go było później rozbudować.

Innymi słowy: nie widzę potrzeby pełnego CQRS teraz, ale chcę, aby później łatwo było ewoluować do niego, jeśli to konieczne.

Tak więc zastanawiałem się, jak rozdzielić polecenia od zapytań, ale obie opierają się na tej samej bazie danych.

Część z zapytaniem byłaby łatwa: usługa danych WCF oparta na widokach ułatwiająca wyszukiwanie danych. Nic specjalnego.

Część polecenia jest trudniejsza, a oto pomysł: polecenia są wykonywane w sposób asynchroniczny, więc nie zwracają wyniku. Ale moje kontrolery witryny ASP.NET MVC często potrzebują informacji zwrotnej z polecenia (na przykład, jeśli rejestracja członka zakończyła się powodzeniem lub nie). Jeśli więc kontroler wysyła polecenie, generuje również identyfikator transakcji (identyfikator) przekazywany wraz z właściwościami polecenia. Usługa poleceń otrzymuje to polecenie, umieszcza je w tabeli transakcji w bazie danych z "przetwarzaniem" stanu i jest wykonywane (przy użyciu zasad DDD). Po wykonaniu tabela transakcji jest aktualizowana, dzięki czemu stan staje się "zakończony" lub "nie powiodło się", a inne bardziej szczegółowe informacje, takie jak wygenerowany klucz podstawowy.

Tymczasem witryna korzysta z usługi QueryService do sondowania stanu tej transakcji, dopóki nie otrzyma "zakończone" lub "nie powiodło się", a następnie może kontynuować pracę w oparciu o ten wynik. Jeśli tabela transakcji jest odpytywana, a wynik został "zakończony" lub "nieudany", pozycja zostanie usunięta.

Efektem ubocznym jest to, że nie potrzebuję guidów jako kluczy dla moich jednostek, co jest dobre dla wydajności i wielkości.

W większości przypadków ten mechanizm odpytywania prawdopodobnie nie jest potrzebny, ale jest możliwy w razie potrzeby. Interfejsy są zaprojektowane z myślą o CQS, więc otwarte na przyszłość.

Czy sądzisz o wadach w tym podejściu? Inne pomysły lub sugestie?

Dzięki!

Lud

Answer 1

Myślę, że jesteś bardzo blisko do pełnego systemu CQRS ze swoim podejściu.

Mam stronę, na której kiedyś robiłem coś podobnego do tego, co opisujesz. Moja witryna, braincredits.com, została zaprojektowana przy użyciu CQRS, a wszystkie polecenia mają charakter asynchroniczny. W rezultacie, kiedy tworzę wpis, naprawdę nie ma informacji zwrotnej dla użytkownika innych niż polecenie zostało pomyślnie przesłane przesłane do przetwarzania (nie przetworzone).

Ale mam wynik użytkownika na stronie (liczba ich "kredytów"), która powinna ulec zmianie, gdy użytkownik przesyła więcej produktów. Ale nie chcę, aby użytkownik nadal naciskał klawisz F5, aby odświeżyć przeglądarkę. Robię to, co proponujesz - mam wywołanie AJAX, które odpala co sekundę lub dwie, aby sprawdzić, czy liczba użytkowników się zmieniła. Jeśli tak, nowa kwota zostanie zwrócona, a interfejs użytkownika zaktualizowany (z odrobiną animacji, aby przyciągnąć uwagę użytkownika - ale niezbyt błyskotliwie).

To, o czym mówisz, to ostateczna spójność - że stan aplikacji, którą zobaczy użytkownik, będzie w końcu zgodny z danymi systemowymi (systemem zapisu). Ta koncepcja jest całkiem kluczowa dla CQRS i, moim zdaniem, ma wiele sensu.Jak tylko pobierzesz dane w systemie (niezależnie od tego, czy jest to oparte na CQRS), dane są stare. Ale jeśli przyjmiesz to i przyjmiesz, że klient ostatecznie będzie spójny, twoje podejście ma sens i możesz zaprojektować swój interfejs, aby to uwzględnić i wykorzystać to.

Jeśli chodzi o sugestie, będę obserwować, ile pollingu robisz i ile danych wysyłasz z powrotem. Czy przejść za burtę z odpytywaniem, co brzmi jak nie jesteś. Ale celuj w to, co powinno być regularnie aktualizowane w witrynie i myślę, że będziesz dobry.

Warstwa danych WCF dla strony zapytań to dobry pomysł - po prostu upewnij się, że jest włączona tylko do odczytu (co na pewno zrobiłeś).

Poza tym, brzmi to jak dobry start.

Mam nadzieję, że to pomoże. Powodzenia!