Wpis z mikrobloga

@Nofenak: Wszystko zależy jak duża aplikacja będzie. Jeśli masz zrobić 3 serwajsy po 4 metody crudowe i tyle case closed, nie rozwijamy tego dalej to pewnie że nie ma się co szczypać w CQRS'a ale jeśli masz dużą i skomplikowaną biznesowo apkę to taki CQRS może pomóc w zachowaniu czystej domeny + zostawia furtke na w miare prostę rozdzielnie bazy write od read
@villager: po prostu nigdy nie robiles nic, do czego CQRS moglby ci sie przydac i nadal nie robisz :)

@Nofenak: tak, to podejscie jest dobre i stosowane, szczegolnie gdy trzymasz tam rowniez dokumentacje np REST w atrybutach albo stosujesz TDD, ulatwia rowniez refaktoryzacje, CQRS rozbija service na handlery, wiec czemu tez nie rozbic controllera na osobne akcje - logiczne nastepstwo, wychodzace od dupy strony :)
@Nofenak: Jeden kontroler do jednej akcji to już przesada, bo jeśli i tak masz na każdą akcję commanda, to nawet jakbyś miał 10 akcji w jednym kontrolerze, nie będzie tam zbyt wiele kodu, ale wydzielenie logiki poszczególnych akcji do osobnych klas zwiększa czytelność i warto tak robić. Nie ma nic gorszego niż mieć jedną metodę na 500 linii albo jeszcze więcej. Taką, że nawet nikt nie podzielił na mniejsze metody prywatne.
@rmweb: w obecnym projekcie mamy takie repo, w pięciu miejscach przekopiowany ten sam kod i zero czasu na zrefaktorowanie tego bo w sumie by trzeba było zacząć wszystko od nowa xd
@szmichal: Przepisać na nowo pewnie zajmie dużo czasu, no ale jeśli jest w pięciu miejscach identyczny kod, to pewnie można szybko przenieść go w inne miejsce i będzie w jednym.