Czy opłaca się wydzielać mikroserwis do walidacji aby uniknąć duplikacji kodu

Ale myślę, że cokolwiek chcesz pogrupować w jakiś sposób można pogrupować też w zupełnie inny.

Co masz na myśli?

Umieszczenie tego w jednym serwisie jest z jednej strony kuszące ponieważ
te 10 mikroserwisów, o których mowa by miało prostą logikę walidacji bo
tylko by wysłały do tego serwisu walidującego listę reguł, które chcą przetestować
i otrzymałyby prostą odpowiedź. Z drugiej strony na pewno będą reguły specyficzne
dla konkretnego serwisu i wrzucanie ich do tego serwisu walidującego trochę mija się
z celem w takim wypadku. Dlatego też trzeba by było oznaczać jakąś flagą każdą
regułę czy jest globalna czy lokalna tylko dla tego serwisu i jeżeli lokalna to przetwarzać
w tym serwisie a te globalne wysyłać do tego serwisu walidującego co też by było brzydkie.

lookacode napisał(a):

Ale myślę, że cokolwiek chcesz pogrupować w jakiś sposób można pogrupować też w zupełnie inny.

Co masz na myśli?

No masz do zaimplementowania ileś procesów, które maja jakieś wspólne podprocesy, których częścią jest walidacja. I masz serwisy od procesów, i chcesz wydzielić do oddzielnego serwisu generyczną walidację.
A może zamiast takiego podejścia należy zaprojektować całość tak, aby generyczne były podprocesy - np. realizacja usługi za opłatą - i wówczas walidacja, czy użytkownika na to stać będzie mogła być w jednym miejscu.

lookacode napisał(a):

Z drugiej strony na pewno będą reguły specyficzne
dla konkretnego serwisu i wrzucanie ich do tego serwisu walidującego trochę mija się
z celem w takim wypadku. Dlatego też trzeba by było oznaczać jakąś flagą każdą
regułę czy jest globalna czy lokalna tylko dla tego serwisu i jeżeli lokalna to przetwarzać
w tym serwisie a te globalne wysyłać do tego serwisu walidującego co też by było brzydkie.

No i tu dochodzimy do tego, co ironicznie opisałem w komentarzu wyżej. :)

I w ogóle nie myślisz jak architekt. Przecież potem trzeba będzie to wszystko synchronizować, wprowadzić wersjonowanie reguł walidacyjnych. A w międzyczasie to w ogóle dostarczymy analitykom biznesowym narzędzie, w którym wyklikają sobie reguły w jakimś GUI, zapiszą do XML, a potem będzie można z nich skompilować nowe binarki z walidacją!

Mikroserwis to nie jest wzorzec projektowy, tylko schemat wdrożenia. Nie wprowadza się takiej architektury, bo łatwiej pisać kod, tylko dlatego, że taniej, bezpieczniej jest go uruchamiać. Potrzebujesz dynamicznie i niezależnie skalować tę walidację? Jak ci padnie walidacja to reszta będzie działać? Zakładając, ze masz 2x nie, to po co chcesz to wydzielać, skoro poniesiesz koszty w postaci wydłużonego czasu obsługi każdego requesta, bo przecież trzeba jeszcze parę razy zawołać po http ten dodatkowy serwis? Jak decydujesz się na uS, to decydujesz się też na to, że jakieś tam kawałki kodu będą powielone pomiędzy komponentami. Chcesz mieć DRY, to zrób monolit i po problemie.
Mogłoby mieć sens stworzenie tego osobnego "bytu", gdyby faktycznie biznes chciał mieć możliwość definiowania sobie reguł walidacji, ale raczej też nie tak, że wysyłasz dane przy każdym żądaniu do mikroserwisu, tylko robisz sobie bibliotekę do sprawdzania reguł walidacji, która raz na jakiś czas dociąga sobie aktualne reguły z uS, który tę konfigurację trzyma.