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?
spring
microservices
użytkownik1176999
źródło
źródło
Odpowiedzi:
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:
Dodatkowe czytanie:
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:
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:
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ódło
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
źródło