Taka sytuacja, do aplikacji wpada ID, po tym ID wyjmuję sobie rekord z bazy i ten rekord jest wysyłany do zewnętrznego mikroserwisu w celu m.in walidacji. Załóżmy teraz, że walidacja się sypnęła. Pojawiło się wymaganie, że obiektom które nie przeszły walidacji trzeba zmienić w bazie 1 pole, załóżmy status. Zmieniamy status, usługa zwraca błąd (HTTP załóżmy 422). Jednocześnie pojawił się głos sprzeciwu, że skoro usługa zwraca klientowi status błedu - 422 to klient nie spodziewa się, że coś zostało zmienione na bazie (w dodatku w transakcji) i to nie ma prawa tak działać. A wymaganie biznesowe jednak istnieje. Pytanie brzmi - kto ma racje - wymaganie czy głos sprzeciwu?
0
4
piszecie apkę dla biznesu czy biznes działa, żeby sponsorować waszą radosną twórczość?
2
Kluczowe jest to, co zmieniasz w tej bazie. Jak to jest status na niezwalidowany to chyba poprawnie. Jak robisz tak, że walidujesz i stwierdzasz, że to jednak jest ok i zapisujesz to nie jest dobrze.
2
Nie wiem, czy dobrze rozumiem.
- Wynik walidacji jest nieistotny, i zmiana w bazie ma być dokonana tak czy siak? To po co w takim razie walidacja?
- Czy chodzi o to, że informacja o nieprawidłowym wyniku walidacji ma być zapisana w bazie?
Bo tak generalnie, to biznes ma rację - nawet jeśli nie ma sensu. ;)
0
somekind napisał(a):
Nie wiem, czy dobrze rozumiem.
- Wynik walidacji jest nieistotny, i zmiana w bazie ma być dokonana tak czy siak? To po co w takim razie walidacja?
- Czy chodzi o to, że informacja o nieprawidłowym wyniku walidacji ma być zapisana w bazie?
Bo tak generalnie, to biznes ma rację - nawet jeśli nie ma sensu. ;)
Chodzi o punkt numer dwa. Jak walidacja się uda to jest dalsze procesowanie, jak się nie uda to ma to zostać odnotowane w bazie, a klient powiadomiony jakąś 400stką.