Wpis z mikrobloga

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 typu CreateOrderDto/ReadAllOrdersDto, też wpada do busa i zamiast handlera jest wyszukiwana odpowiednia komenda/query np. CreateOrderCommand, która implementuje interface Command z metodą execute(T t) gdzie T to jakieś dto. Co o tym myślicie i jakiego podejścia używacie?
#programowanie #naukaprogramowania #cqrs
  • 4
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@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
@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