Dwie solucje i jedna baza - podejście DB First (migracje) i komunikacja między projektami

Witam

Do tej pory tworzyłem głównie monolity.
Obecnie mam do zrealizowania projekt gdzie część frontowa musi z pewnym przyczyn (zależnych od integracji z aplikacją zewnętrzną) znajdować się w jednej solucji razem z mechanizmami backendowymi w obszarze logowania i rejestracji użytkownika. Nazwijmy go moduł "A".

Druga solucja to część czysto backendowa gdzie będą realizowane wszystkie pozostałe procesy niezwiązane z zarządzaniem użytkownikiem i logowaniem.
Nazwijmy go moduł "B".

Taka organizacja tej aplikacji wynika z pewnych podziałów w organizacji w której pracuje gdzie są zespoły programistów backend i frontend i jest mocny rygor aby jedni drugim nie wchodzili w drogę "w kod".

Moje pytania są następujące.

1. Jak komunikować ze sobą te dwa "moduły" tj za pomocą jakiego narzędzia? Moduły będą wystawiały endpointy w ramach API.
   Czy np moduł "A" powinien udostępniać informacje dla modułu B (lista użytkowników, informacje o kontekście użytkownika, jakieś inne dane użytkownika)?
   Czy jako, że moduł "A" i moduł "B" łączą się do tej samej bazy to moduł "B" powinien sam sobie wydobywać informacje, które są wytwarzane i zarządzane w ramach modułu "A"?
   I tutaj przechodzę do pytania numer 2 tj współdzielenia migracjami...

2. Jak pomiędzy tymi dwoma modułami zarządzać migracjami?
   Czy można realizować migracje do jednej bazy w ramach dwóch solucji (oddzielne projekty na GitLabie)?
   Jeśli tak to jak? Jak aktualizować dane o tabelach, które powstały w ramach migracji w module A?

Pierwsze i podstawowe, moim zdaniem, pytanie - skąd wymóg, by oba moduły korzystały z jednej bazy?
Czy jest między nimi jakiekolwiek powiązanie w logice biznesowej czy są to osobne byty zamykające się w osobnych kontekstach?

Bo na pierwszy rzut oka brzmi to jakby moduł A odpowiadał jedynie za warstwę uwierzytelnienia/autoryzacji oraz zarządzaniem użytkownikami, czy tak?

Jeśli tak, to dlaczego nie miałby mieć swojej, osobnej bazy?
Wtedy jedyne co należy uzgodnić między zespołami to kwestia uprawnień i styku w warstwie technicznej na poziomie auth.

Czyli flow (w mega uproszczeniu) miałbyś taki:

1. Użytkownik loguje się do systemu przez auth server,
2. Auth Server generuje odpowiedni auth token, który odsyła na front (i który jest akceptowany przez oba moduły),
3. Użytkownik korzystając z aplikacji pod spodem przesyła żądania do modułu B, przesyłając również ten wygenerowany token w ramach uwierzytelnienia/autoryzacji,

W ten sposób masz dwa niezależne moduły i nie bawisz się z koszmarnym zarządzaniem stanem bazy

Klojtex napisał(a):

Pierwsze i podstawowe, moim zdaniem, pytanie - skąd wymóg, by oba moduły korzystały z jednej bazy?
Czy jest między nimi jakiekolwiek powiązanie w logice biznesowej czy są to osobne byty zamykające się w osobnych kontekstach?

Bo na pierwszy rzut oka brzmi to jakby moduł A odpowiadał jedynie za warstwę uwierzytelnienia/autoryzacji oraz zarządzaniem użytkownikami, czy tak?

Jeśli tak, to dlaczego nie miałby mieć swojej, osobnej bazy?
Wtedy jedyne co należy uzgodnić między zespołami to kwestia uprawnień i styku w warstwie technicznej na poziomie auth.

Czyli flow (w mega uproszczeniu) miałbyś taki:

1. Użytkownik loguje się do systemu przez auth server,
2. Auth Server generuje odpowiedni auth token, który odsyła na front (i który jest akceptowany przez oba moduły),
3. Użytkownik korzystając z aplikacji pod spodem przesyła żądania do modułu B, przesyłając również ten wygenerowany token w ramach uwierzytelnienia/autoryzacji,

W ten sposób masz dwa niezależne moduły i nie bawisz się z koszmarnym zarządzaniem stanem bazy

Moduł "A" - logowanie, dodawanie użytkowników, nadawanie uprawnień.

Jeśli byłyby to dwie bazy to jak w ramach modułu B i jego oddzielnej bazy miałbym przechowywać informacje o użytkowniku, który wykonał jakąś akcję?
Np wygenerował jakiś dokument. Tam muszę posiadać np imię, nazwisko, stanowisko i jego identyfikator.
W ramach jednej bazy wrzuciłbym tam tylko jego identyfikator i podczas wyświetlania jakiegoś zbioru danych bym tylko pobierał po referencji do tabeli "User" jego dane.
Jak tutaj to rozwiązać? Przechowywać w bazie modułu "B" identyfikator użytkownika z bazy modułu "A" i później pobierać dane o użytkowniku z dedykowanego endpointa z API modułu "A" ?

Poza tym zapisuje też dane audytowe w tabelach tj. jaki użytkownik utworzył wpis w tabeli czy kto zmodyfikował dany wiersz.
Jak to pogodzić pomiędzy dwoma bazami?
Druga kwestia jest taka, że kontekst użytkownika tworzą też informacje słownikowe, które występują też później w ramach składanego dokumentu przez tego użytkownika.
Czyli ten słownik to ma się wtedy w której bazie znajdować? W jednej i drugiej?

Klojtex napisał(a):

3. Użytkownik korzystając z aplikacji pod spodem przesyła żądania do modułu B, przesyłając również ten wygenerowany token w ramach uwierzytelnienia/autoryzacji,

"Aplikacja pod spodem" czyli front ?