Wszystko

Najnowsze

Archiwum

daro1
  • 1
W dwóch moich projektach w PHP opartych na Koseven wdrożyłem CQRS i to w dość prosty sposób w prostych CRUD-ach i jedyne co mogę powiedzieć to to że ma to same zalety, nie widzę wad (jak na rozmiar tych aplikacji) i zbytniej komplikacji kodu, tylko nie wiem czy to podejście które zastosowałem jest do końca prawidłowe. Tak jak przeglądałem niektóre tutoriale i kody na github temu poświęcone, realizacja w PHP wygląda tak.
  • 26
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
Serghio
  • 4
@daro1: Powiedziałbym tak - jak zawsze wszystko zależy od konkretnego przypadku architektury aplikacji i konkretnych potrzeb.

Czasami opieranie wszystkiego, zwłaszcza CRUD encji o CQRS nie ma sensu, a najchętniej darowałbym sobie używanie encyklopedycznego "Query" (mowa oczywiście tylko o języku PHP), gdy mamy jednocześnie używamy ORM.

Może opowiem, w jaki sposób ja tego
  • Odpowiedz
E.....r
E.....r
  • 0
Typowa implementacja CQRS wygląda mniej więcej tak: Użytkownik wysyła jakieś command albo query, potem to wpada do busa, który używa odpowiedniego handlera, obsługującego to zapytanie i w sumie tyle. Brzmi prosto i sesnownie tylko jest jeden taki problem, że powstają klasy o długich i skomplikowanych nazwach typu "CreateOrderCommandHandler implements CommandHandler". Dlatego właśnie szukam jakiś sensownych alternatyw dla nazw i póki co to wymyśliłem coś takiego: Od użytkownika leci po prostu jakieś dto
  • 4
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
Cimcirimcipiririri
  • 1
@Edelner: Nie żeby coś ale wbije trochę kij w mrowisko, przecież chyba po to właśnie tworzymy te sugestywne nazwy klas (CreateSthCommand, GetSthQuery) żeby na pierwszy rzut oka wiedzieć po co ta klasa jest i że dane w tej klasie będą wykorzystane tylko i wyłącznie do przetworzenia tej jednej akcji, wtedy mamy pewność że nie rzucamy sobie tym commandem czy też query po całym systemie jak to ma miejsce w Dto'sach.
  • Odpowiedz
Whiskeyjack29
Whiskeyjack29
  • 1
@Edelner: Tragiczny pomysł query i command to nie dto - dwie konceptualnie zupelnie inne rzeczy sufixQuery i Command bym zostawił, prefix get można usunąć z query chociaż nie polecam, w handlerach można zlikwidować słowo query i command i nie pozbawia to ich czytelności. Ważne żeby nie robić smurf coding to prowadzi do tragicznych nazw np w namespace customerOrders lub customers nie trzeba każdego orderu prexiksowac na zasadzie GetCustomerOrdersHandler GetLastCustomerOrderHandler wystarczy
  • Odpowiedz
Hauleth
  • 1
@Edelner: Oba są zupełnie niezależne od siebie, więc możesz mieć oba. Tak, command nic nie powinien zwracać, ale nic nie stoi na przeszkodzie by kontroler wykonał wpierw command a potem query i dopiero to zwrócił.
  • Odpowiedz
badAttitude
  • 1
Siema Mireczki, chciałbym into cqrs + es przy użyciu spring cloud stream + kafka trochę już o tym poczytałem ale tylko to zrodziło więcej pytań mianowicie załóżmy, że mamy zwykłą rejestrację użytkownika plus jego późniejszą autentykacje, czyli założenie konta + credentali (login/haslo) + wysłanie linka z potwierdzeniem i po aktywacji konta i podaniu login/hasło wygenerowanie jwt.

Logiczne wydaje się to rozbicie na 3 serwisy

- user serivce
- auth service
  • 2
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
maniserowicz
  • 2
Na #devstyle o #cqrs. Jak pogodzić kontrakt komendy (void) z faktem, że czasem trzeba zwrócić jakiś wynik?
http://devstyle.pl/2016/11/29/jak-zwrocic-rezultat-wykonania-komendy-w-cqrs/

W tekście "CQRS+DI w C# i Autofac" pokazałem, że CommandHandler nie zwraca żadnego rezultatu wykonania komendy. Natomiast w "Esencja CQRS" pisałem, że jest to jedna z zasad, co do której można się spierać. Więc... jak to faktycznie jest? Jak zwrócić rezultat wykonania komendy w CQRS?

Zapraszam na
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
M.....v
  • 0
@budyn: Też jestem nim ostatnio zawiedziony trochę. Bardzo krótkie artykuły; jakieś śmieszne artykuły o Unity3D, kilkuzdaniowe teksty o testach, które nic nie wnoszą.

Lessa wrzuciłem, bo uznałem, że to ciekawe wprowadzenie i napisał te 3 artykuły. Jak się je postawi obok siebie, to jest trochę treści.
  • Odpowiedz
markaron
  • 1
W event sourcingu możemy zdefiniować wiele handlerów dla jednego typu zdarzenia. Jaką konwencję organizacyjną handlerów przyjęlibyście w takiej sytuacji:

System A wysysła do B wiadomość. System B po odebraniu wiadomości emituje zdarzenie MessageReceived. W wyniku tego zdarzenia mają wykonać się następujące operacje:
- zapis informacji do logu aplikacji o odebranej wiadomości,
- umieszczenie wiadomości w kolejce, skąd zostanie odebrana przez inny system
- wysłanie informacji o odebranej wiadomości do serwisu odpowiedzialnego za monitorowanie obsługiwanych zdarzeń w
markaron - W event sourcingu możemy zdefiniować wiele handlerów dla jednego typu zdar...

źródło: comment_Z8kISSVB9OfJ2yRUUpdxx7usuXWd5L7V.jpg

Pobierz
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
fenix7557
  • 0
@Maav: ciekawe te local functions. Dlaczego dopiero teraz i co argumentowało za tym by je zrobić? Nie pisałem poważnych systemów żeby móc to dobrze ocenić ale czasem brakowało mi takiej rzeczy. Możliwości zdefiniowania funkcji, żeby w dalszym bloku jej użyć kilkukrotnie, ale z kolei nigdzie indziej już tego nie potrzebowałem i szpeciła metoda w klasie. Obchodziłem się z tym tak, że tworzyłem Actiony, ale dla totalnego ładu i składu brakowało
  • Odpowiedz

Powiązane tagi