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

Załóżmy, że mamy X mikroserwisów i każdy z nich waliduje podobne lub takie same reguły biznesowe.
Czy warto w takim przypadku wydzielić osobny mikroserwis Y w celu deduplikacji, który by walidował te reguły i te X mikroserwisów
wywoływało by Y w celu walidacji. Walidacja polegałaby na tym, że Y wywoływał by inne zewnętrzne usługi np.
sprawdzając czy użytkownik ma konto albo środki na koncie itp. Y by wystawiał proste api gdzie na wejściu
(w uproszczeniu) by przyjmował różne asercje np.

[
"user_has_account",
"user_has_funds",
"premium_is_enabled"
]

I na wyjściu by zwracał true / false.
Czy coś takiego ma sens?

Nie ma sensu, potem wprowadzenie nowej walidacji w jakiejkolwiek domenie będzie wymagało zmiany w tym uber-serwisie - zero autonomii zmiany.

Jeżeli tych mikroserwisów będzie 10 to wtedy powtarzać 10x tą samą logikę? Do libów tego nie wrzucę bo do libów kodu biznesowego się nie wrzuca.

a skąd bierzesz usera? - też masz w 10 miejscach kod pobierania usera?

Te asercje typu user_has_funds itd. to tylko przykład niektóre nie muszą być związane z tym w kontekście jakiego użytkownika to jest. I tego typu asercje bedą pobierane z bazy przez te mikroserwisy. Chodzi o to, że ktoś z GUI może sobie dynamicznie zmienić pod jakimi warunkami coś się zadzieje lub nie albo coś się wyświetli lub nie wyświetli.

W związku w powyższym jeżeli w mikroserwisie A jak i B dodana zostanie reguła do czegoś np. niech będzie premium_is_enabled to skoro te reguły mogą się powtarzać pomiędzy tymi serwisami to dlaczego powtarzać pisanie „handlerow” do tych reguł.

Na razie tylko myślę nad designem tego. Jeszcze nie powstała żadna linijka kodu.

lookacode napisał(a):

Jeżeli tych mikroserwisów będzie 10 to wtedy powtarzać 10x tą samą logikę? Do libów tego nie wrzucę bo do libów kodu biznesowego się nie wrzuca.

Nie generalizowałbym (choć w tym przypadku wszystko wskazuje na to, że masz rację). Logiki nie umieszczamy w bibliotekach, bo zazwyczaj to serwisy i ich podział temu służą. Ale są też inne powody na podział np. performance/reliability. Przykładowo piszemy serwisy w taki sposób, że każdy serwis odpowiada za integrację z innym klientem zewnętrznym a nad nimi jest jakiś master serwis, który to wszystko koordynuje. Może okazać się tak, że dużo prościej jest umieścić wspólny kod w libie a te serwisy odpowiedzialne za kontakt ze światem zewnętrznym ich używają. W tym wypadku największy problem umieszczania logiki w wspólnym module, czyli różne serwisy ze sobą gadają a każdy używa innej wersji tej samej biblioteki jest minimalizowany, bo jedyna komunikacja jaka się odbywa to serwis A, serwis B/serwis C <-> master serwis i nie ma problemu, że serwis A używa starej wersji, bo serwis C ma to gdzieś.

A czemu w ogóle istnieje możliwość, że te same reguły są sprawdzane przez wiele różnych mikroserwisów?

Nie, sensowna wielkosc mikroserwisu jest zdecydowanie wieksza niz sie ludziom wydaje. W szczegolnosci jak to trzerba na produkcji potem utrzymac. Do tego sumarycznie bedziesz mial podobne zuzycie CPU i pamieci a mocno dociazysz siec.

somekind napisał(a):

A czemu w ogóle istnieje możliwość, że te same reguły są sprawdzane przez wiele różnych mikroserwisów?

A czemu nie? Np. jak jest wiele mikroserwisów i każdy z nich realizuje pewną usługę dla użytkownika, za którą
on musi oczywiście zapłacić to reguła np. user_has_funds pewnie będzie się powtarzać w nich wszystkich

No to w takim razie może powinien się tym zająć serwis od realizacji pewnej usługi dla użytkownika?

Tak tylko gdybam, bo trudno zgadywać nie znając kontekstu biznesowego ani domeny. Ale myślę, że cokolwiek chcesz pogrupować w jakiś sposób można pogrupować też w zupełnie inny.

Bo jak zrobisz taki oddzielny serwis do walidacji, to potem będziesz się zastanawiał, czy dawać tam każdą walidację, czy tylko taką dzieloną między wieloma serwisami. Mam wrażenie, że tak czy siak powstanie wtedy bałagan.

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.