jaka architektura mikroserwis + UI

Mam pewnie dość proste pytanie odnośnie najlepszych praktyk, to mój pierwszy mikroserwis i chciałbym go zrobić po bożemu
Mikroserwis (M) wymaga pewnych metadanych i UI do konfiguracji będzie w istniejącej aplikacji (A) typu monolit

• czy wobec tego encje jpa mogą być współdzielone między M i A w postaci jara czy raczej to oznacza zły design ?
  • może nie w tym przypadku ale wydaje mi się że tak izolacja jest czasami dość trudna do zrealizowania
• czy M powinien zapewniać całą logikę wobec czego
  • UI musiałby komunikować się z M i musiałbym pomyśleć jak podejść do autoryzacji
  • A robi za proxy między UI i M
• tak czytałem o mikro-frontendach https://altkomsoftware.pl/blog/ui-in-microservices-world/ ale raczej nie tym razem

Dalej, w (M) mam potrzebę doczytania z bazy jakiś danych konfiguracyjnych. Z różnym powodów wolałbym je przeczytać z bazy niż z kolejnego microserwisu
Mam już taki kod w (A) ale zakładam że powinienem te encje i serwis wydzielić do osobnego jara. Tylko z takim podejściem to boję się że za chwilę będę miał dziesiątki jarów. Nie wiem może na wyrost

czy wobec tego encje jpa mogą być współdzielone między M i A w postaci jara czy raczej to oznacza zły design ?
może nie w tym przypadku ale wydaje mi się że tak izolacja jest czasami dość trudna do zrealizowania

Mikroserwis nie powinien mieć wspólnego jara z modelem bazodanowym

Dalej, w (M) mam potrzebę doczytania z bazy jakiś danych konfiguracyjnych. Z różnym powodów wolałbym je przeczytać z bazy niż z kolejnego microserwisu

Powinieneś mieć jakiś central config IMO. Czemu w M nie trzymac jakiś tam konfiguracji w ramie, a jak konfiguracja będzie się zmieniać to propagować jakąś Kafką czy JSMem

Poczytaj o Anti-Corruption Layer, Bounded Contextach i Single Source of Truth.

Jak zrobisz taki coupling, o jakim piszesz będzie to trudne w rozwoju i utrzymaniu. W zasadzie to zrobiłbym 2 kroki wstecz i ustalił po co robisz osobny mikroserwis?

Dla mnie skoro A zarządza tymi danymi to są to jego dane i powinny być wystawione dla M jako jakiś interfejs i tyle. M w ogóle nie wie że te dane pochodzą z jakieś "bazy" bo i niby po co mu to wiedzieć? A może są trzymane tylko w pamięci? A moze w jakimś noSQLu albo w pliku na dysku? :)

@Charles_Ray: Przeczytałem, wydaje mi się że rozwiązanie z A jako proxy było by zgodne SST i BD. ACP musiałbym zobaczyć przykład
Case jest prosty: chcę wystawić rest api dla dostawców danych. Mógłbym bez problemu to zrobić w A ale A

• jest już dość duża
• nie ma i nie będzie mieć autoskalowania
• bazuje jeszcze na 1.8
• nic nie powinno zakłócać pracy użytkowników
  więc oczywisty pomysł to samodzielne serwisy, może to nie jest pełnoprawny mikroserwis tylko taki rodzaj workera/konsumenta
  Teraz co do UI potrzebuję konfigurować np dostawców, format danych itd itd. Klient pracuje z A, przełączanie się inną aplikację to słaby pomysł
  więc M musiało by renderować część strony - to pewnie było rozwiązanie "czyste" z punktu widzenia separacji odpowiedzialności jeśli A potraktujemy jako fasadę, chociaż z drugiej strony wymagało by A do działania.
  Tylko technicznie to widzę same wady takiego rozwiązania

Edit. Już chyba załapałem o co chodzi i chyba nie powinienem mówić o mikroserwisie. Bo np w A chciałbym wyświetlić dane powiązane z danym customerem które mamy od dostawcy X to normalnie były zwykły prosty selekt do bazy to teraz powinienem odpytywać M, a przypadku jeżeli robię jakieś obliczenia w oparciu o te dane to będzie za wolne

Nie do końca rozumiem co chcesz zrobić, ale:

1. M nie musi nic renderować, tylko dostarczać dane, które A wyświetli. Musisz się oczywiście zastanowić co w przypadku niedostępności M lub timeoutu - wprowadziłeś przecież sieć po drodze.
2. Sieć wprowadzi opóźnienie rzędu kilkudziesięciu milisekund, to nie powinna być tragedia. Jakby było słabo może można wprowadzić jakiś cache w zależności co to za dane.
3. Wszelkie modyfikacje tych danych pobieranych z M musza być robione w M, bo tam chronisz spójności modelu. Jak go wyświetlasz w A to obojętne. Zastanów się jaka cześć modelu możesz wydzielić z A do M.