Wielodostępna Architektura CQRS

Mój zespół rozpoczyna wdrażanie aplikacji greenfield, z wymogiem multi-tenancy. Wykonałem wiele badań na temat wzorców dla prostej skalowalności, zwłaszcza na rozproszonej infrastrukturze opartej na chmurze, a CQRS wydaje się być buzzword du jour (idąc tak daleko, jak nazywa się "Crack for Architecture Addicts", co uważam za dość zabawne). Korzyści i pułapki na bok, to jest dość trudno znaleźć kogoś oprócz Greg Young, który wykorzystał ten pomysł szeroko (lub w ogóle) w aplikacjach produkcyjnych i może zapewnić rzeczywiste wskazówki dla niego.

Oto moje pytania: 1. Czy architektura CQRS pasuje do typowej aplikacji wielodostępnej, czy lepiej nadaje się do większych wewnętrznych aplikacji korporacyjnych. 2. Jeśli zalecasz, że jest on używany w tej sytuacji, czy możesz podać pewne wskazówki od-The-okopy na podejścia-zwłaszcza na rzeczy, aby uzyskać prawo na początku, i jakie aspekty powinny być ewoluowane organicznie. 3. Jeśli ktoś próbował i uznał to za zbyt trudne lub nie zdał sobie sprawy z korzyści, lub ma mocne argumenty przeciwko niemu (i zaleca trzymanie się CRUD i warstwowego projektu), chciałbym wiedzieć o tych doświadczeniach, jak również.

Dla odniesienia, aplikacja zostanie napisana w. NET, a front end będzie początkowo oparty na sieci web (ASP.NET MVC), potencjalnie rozszerzony na klientów mobilnych i grubych. Oczekuje się, że współbieżność, aktywność transakcyjna i wolumen danych pozostaną stosunkowo niskie w całym żywotność aplikacji(w porównaniu do dużych aplikacji finansowych i tym podobnych). W przypadku infrastruktury planujemy korzystać z platformy Azure.

Author: Mafuba, 2010-12-15
Source

3 answers

Sam zbadałem ten sam punkt wyjścia, z perspektywy rozpoznawczej przed rozpoczęciem rzeczywistego projektu (wciąż czekamy na finansowanie biznesu). W tym, moje badania i opinia powstała z nich jest to, że oś multi-tenant architektury jest w dużej mierze ortogonalny do wykorzystania CQR do wewnętrznego projektowania gruboziarnistego usługi. Wymóg multi-tenant nakłada dodatkowe nadrzędne ograniczenia dotyczące sposobu, w jaki aplikacja segreguje najemców z bezpieczeństwo, dane, prezentacja/Personalizacja, wdrażanie/udostępnianie i skalowalność. CQRS tak naprawdę nie czyni tego lepszym lub gorszym i moim zdaniem nadal ma wartość w rozwiązywaniu cennych wyzwań architektonicznych dla usług. Jednak nie wszystkie usługi, które luźno współpracują w celu zapewnienia aplikacji, muszą być zgodne ze wzorem CQRS, pod warunkiem, że wybrana luźno powiązana Architektura nie zabrania jej używania.

 6
Author: Dokie,
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
2011-03-09 14:17:02
  1. Multi-tenancy zmieni nieco stronę odczytu CQRS. Musisz filtrować widoki i zwracać tylko dane związane z dzierżawcą. I napotkasz te same problemy przy użyciu każdej innej architektury.
  2. polecam CQRS, ponieważ sprawi, że Twoja aplikacja będzie oparta na zadaniach (a nie na CRUD). Oznacza to, że będziesz mieć polecenia otrzymane z interfejsu użytkownika i będą one bardziej znaczące niż DTOs. Jeśli chcesz napisać swój rdzeń z zasadami DDD to staraj się unikać anemicznego modelu domeny ( http://martinfowler.com/bliki/AnemicDomainModel.html ). Podejście do tego - przenieś całą logikę specyficzną dla domeny do obiektów domeny. Twoje programy obsługi poleceń powinny być bardzo proste (uwierzytelnianie, załaduj zagregowany root, Przetłumacz obiekt polecenia na wywołanie metody, jeśli nie wyrzucono WYJĄTKÓW-Zastosuj zmiany). Warto obejrzeć zapis zajęć Grega (6 godzin i pół): http://cqrsinfo.com/video/ Jak powiedział Michael Shimmins, jeśli planujesz używać Azure jako swojej platformy-warto przyjrzeć się Lokad.Projekt CQRS. Wykorzystałem go do realizacji jednego z naszych projektów.
  3. CQRS nie zmieści się, jeśli naprawdę potrzebujesz prostej aplikacji CRUD (nie opartej na zadaniach). CQR wymagają więcej czasu, aby zrozumieć zasady dla początkujących. Z drugiej strony pozwoli to na rozdzielenie zadań dev pomiędzy programistów domenowych i mniej doświadczonych programistów view- > dto - > UI.
 7
Author: Vsevolod Parfenov,
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-12-25 07:51:44

Nie sądzę, aby multi-tenant był trudniejszy/łatwiejszy przy użyciu CQRS. Korzystanie z wiadomości ma wiele zalet: możesz osadzić identyfikację dzierżawcy w poleceniach i zdarzeniach jako dane nagłówka, wybrać magazyn zdarzeń na podstawie identyfikacji, połączyć wiele dzierżawców z wieloma instancjami. Mimo to zadaj sobie pytanie, czy Twoja domena jest wysoce współpracująca i masz do dyspozycji eksperta ds. domen ... w przeciwnym razie kończy się komenda / event-cud; -)

 2
Author: Yves Reynhout,
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-12-15 10:23:08