Modele domeny wspólnej architektury mikrousług

Załóżmy, że mamy aplikację Spring Boot, która korzysta z architektury mikrousług. Każda z usług ma własne modele domen, ale każda usługa musi odwoływać się do obiektu domeny użytkownika. Jakie byłoby najlepsze podejście do rozwiązania tego problemu? Czy byłoby lepiej, gdyby każda usługa miała tylko identyfikator użytkownika, a następnie, w razie potrzeby, pytała usługę użytkownika o szczegóły użytkownika, czy byłoby lepiej mieć wspólną bibliotekę domen dla wszystkich mikrousług?

Jeśli zdecydowałeś się na mikrousługi, aby skorzystać ze skalowalności, luźnego sprzężenia i łatwej niezależnej modyfikacji każdej usługi, powinieneś trzymać się jej w maksymalnym możliwym zakresie.

Ogólna architektura

Myślę, że najlepszym podejściem byłoby:

• mieć mikrousługę do ogólnego zarządzania informacjami o użytkowniku;
• przechowuj informacje o użytkownikach dotyczące mikrousług (np. profile, autoryzacje, preferencje) w każdej mikrousługie (używając referencji ogólnego identyfikatora)

Dodatkowe czytanie:

• W tym artykule bardzo dobrze opisano tego rodzaju architekturę i uzasadnienie, ze szczególnym przypadkiem autoryzacji.
• W tym artykule opisano wyzwania i rozwiązania dotyczące zarządzania tożsamością użytkownika, aby uniknąć wszystkich usług mających dostęp do tego samego repozytorium.
• W tym artykule opisano, jak używać JWT do przekazywania tożsamości użytkownika między usługami (zauważając, że w tokenie id można podać podstawowe informacje, co pozwala uniknąć konieczności ponownego wysyłania zapytania do usługi użytkownika po zalogowaniu, przynajmniej w przypadku bardzo podstawowego Informacja).

Udostępnianie kodu

Teraz, jeśli zgadzasz się na powyższe rozwiązanie, mamy mikrousługę użytkownika (enkapsulujący model domeny dla użytkownika), a wszystkie inne usługi są konsumentami tej samej mikrousługi. Pytanie brzmi, czy chcesz:

• każdą mikrousługę, aby na nowo opracować kod konsumenta, zgodnie z dogmatem silnej separacji umożliwiającej elastyczne i odrębne cykle uwalniania
• lub udostępnić kod konsumenta jako część biblioteki, biorąc pod uwagę, że ta podstawowa informacja jest rozszerzeniem wzorca infrastruktury „podwozia” .

Nie zajmę jednoznacznego stanowiska w tej sprawie, ponieważ toczą się opinie o wojnach opiniujących ten temat dotyczący udostępniania kodu i nie sądzę, żebym był w stanie zająć obiektywne stanowisko. Oto już kilka dodatkowych lektur:

• Ten artykuł uważa, że ​​nie ma najlepszego rozwiązania, a wszystko zależy od twoich celów
• Ta pozycja artykułu jest taka, że ​​dzielenie kodu jest złe tylko wtedy, gdy tworzy silne połączenie, a dzielenie kodu może przynieść pewne synergie
• W tym artykule (osób, które wdrożyły mikrousługi na dużą skalę) nalega się na konieczność posiadania osobnych kompilacji i potencjalne problemy z wycofaniem starszego kodu. Posiadanie wspólnej biblioteki dla spożywania stałym zarządzania wersjami nie zabrania takich praktyk dobre.

Uważam, że NIE WOLNO PODDAĆ kodu między dostawcą użytkownika a konsumentem użytkownika, aby uniknąć ścisłego powiązania. MUSISZ PODZIELIĆ kod konsumpcji użytkowników między konsumentami, jeśli masz silne zarządzanie wersjami. Takie podejście miałoby pewne zalety:

• Różne mikrousługi konsumujące użytkowników mogą być budowane z różnymi wersjami wspólnego kodu konsumpcji użytkowników (o ile wersje są kompatybilne z niezależnym dostawcą użytkowników). Ta sama elastyczność, co nowe odkrycie koła, ale wyższa wydajność.
• Możesz zmienić usługę dostawcy usług dla użytkownika niezależnie, bez wpływu na konsumentów.
• Jeśli błąd zostanie znaleziony po stronie konsumpcji, możesz go poprawić raz i wdrożyć wszystkich klientów w najlepszy sposób (dzięki zarządzaniu wersjami). Może to nawet doprowadzić do wyższej jakości usług.
• Jeśli z jakiegoś powodu musisz zaktualizować interfejs API dostawcy-użytkownika, możesz wdrożyć zaktualizowane informacje o zużyciu użytkowników w szybszym tempie. Jeśli podczas przejścia utrzymasz aktywność starej i nowej usługi dostawcy, ta możliwość udostępniania może pozwolić na szybsze wycofanie starszej wersji dostawcy-konsumenta.

Unikałbym wspólnej biblioteki, jeśli to w ogóle możliwe. Zadaj sobie pytanie, jakich właściwości użytkownika potrzebuje każda usługa? Często istnieje podstawowa domena, w której żyje większość zachowań otaczających użytkownika, przy czym domeny wspierające często wymagają tylko identyfikatora użytkownika.

Jeśli usługa wymaga pewnych innych szczegółów dotyczących użytkownika, rzucić okiem na kilka sugestii tutaj dotyczącą jak radzić sobie w takich sytuacjach