Temat: CQRS (Command Query Responsibility Segregation), wasze...
Michał Jasiorowski:
Bartosz Adamczewski:
Temat Ciekawy.
Ale z czym jest to lepsze od N-TIER czy Middleware Tier?
Ok, być może źle mnie zrozumiałeś. Nie napisałem, że lepszy, tylko, że jest alternatywą dla architektury N-Tier dla specyficznych aplikacji.
Zgadzam się, jest ona dużo bardziej złożona (i cięższa w implementacji) niż N-Ter, jednak tak jak można przeczytać w artykułach wymienionych wcześniej autorów w ponad 90% przypadków można znaleźć i użyć lepszej niż ta.
Jej przewagę widać w systemach które muszą posiadać bardzo dużą skalowalność, dużą dostępność oraz posiadają skomplikowaną domenę.
Generalnie rozumiem to podejście. Natomiast poza wydajnością o której napisałeś nie widzę więcej potencjalnych korzyści, które różniły by tą architekturę od middleware (przez middleware rozumiem komponent kolejkujący i wysyłający requesty dalej do modułów, wyobraź to sobie jak pojedyncze AC).
---
1. Co do propagacji błędów to w przypadku middleware błąd będzie propagowany tylko tam gdyż nawet jeśli moduł będzie wymuszał flow obejmujący wiele innych modułów i tam wystąpi błąd to wszystkie te kroki będą obsługiwane przez middleware i logowane więc propagacja błędu zatrzyma się tam (nawet jeśli błędne dane będą przesłane dalej), więc taki błąd będzie wykrywalny bardzo szybko.
w przypadku CQRS taka propagacja jest możliwa po przez implementacje w każdym AC event publishera do tzn monitor AC, co komplikuje implementacje jako że ta funkcjonalność jest out of the box w middleware, więc suma sumarum jest to wykonalne i widzę ogromne korzyści że można po prostu napisać takie AC ale złożoność i czas na to potrzebny rośnie.
2. Kolejnym potencjalnym problemem, który widzę to tak jak powiedziałeś każdy AC będzie posiadał swoją domenę więc w przypadku komunikacji wielu AC dane muszą być konwertowane na domenę tego AC, czy nie lepiej w takim razie mówić o danych niż mówić o domenach, oraz manipulować danymi niż domenami?. Inaczej jeśli logika będzie wymagać uwikłania wielu AC to dane będą musiały być reprezentowane za każdym razem inaczej w kontekście danej domeny.
Jest oczywiście jak najbardziej możliwe uogólnienie domeny tak aby wszędzie manipulacja danymi przebiegała w ten sam sposób ale to łamie troszkę idee tego wzorca.
3. Dlaczego komendy powinny sięgać do bazy?, komenda powinna być bardzo lekka oraz nie sięgać nigdzie wg mnie. W przypadku CQRS żeby utworzyć komendę musimy sięgnąć do bazy co wydaje mi się zbędne.
Komenda wg powinna zawierać tylko komendę :-) i to wszystko, resztę AC odczyta z requesta, który dostanie wtedy AC powinien dopiero walidować komendę w kontekście danych to wg może znajdować się w bazie, Autor dodatkowo sugeruje że komendy to osobne solucje więc czy należy to rozumieć że komendy będą mieć jakaś skomplikowaną implementacje? Jeśli tak to taki podeście wydaje mi się zbyt skomplikowane.
W przypadku middleware komendy są lekkie i powiązane z requestem, to middleware je waliduje oraz wie co z nimi zrobić, tam następuje sprawdzenie z bazą, we komenda może zarządzać wykonania pewnej operacji, która zawiera skomplikowaną logikę oparta na odpowiedziach z modułu ale taki operation set jest trzymany po stronie bazy bądź plików w middleware.
Podsumowując architektura jest bardziej skomplikowana, ale daje w zamian kilka ciekawych rzeczy jak kompletne rozproszenie, jednak osobiście dla mnie zbyt skomplikowana to co osobiście bym zrobił to szukał miejsc gdzie można ją znacznie uprościć, bo doświadcznie pokazuje że już prostsze architektury przy +5 mln lines of code robią się zbyt skomplikowane oraz odporne na zmiany :-).
пропозиції роботи
