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.