Klasy wykorzystywane między mikroserwisami

Cześć.
Mam pytanie dotyczące mikroserwisów. Pracuję od niedawna w Niemczech gdzie trafiłem do stosunkowo nowego projektu.
Sam nie mam dużego doświadczenia stąd moje pytanie. Mamy kilka mikroserwisów które komunikują się między sobą za pomocą RESTa, i czasami wysyłają jakieś bardziej złożone dane między sobą. Dla przykładu weźmy że są to 3 mikroserwisy. Jeden z nich wysyła POST z danymi faktury, klienta itp (nieistotne, w każdym razie dość mocno rozbudowany obiekt agregujący inne obiekty itp) do pozostałych dwoch serwisów.
Co robią firmie? Żeby po drugiej stronie odebrać te dane a nie uzależniać od siebie serwisów, kopiuj-wklej tych samych klas w pozostałych mikroserwisach. Dzięki temu mamy np. kilkanaście klas identycznych co jest moim zdaniem absurdem bo korygując jedną, należy pamiętać aby poprawić kolejne.
Pytanie więc jak taki problem rozwiązać? Gdzie umieszczać klasy które wykorzystywane są w 2,3 albo i większej ilości mikroserwisów?

Pozdrawiam,
eL

Klient serwisu może być wykonany w innej niż serwer technologii, może nie potrzebować najnowszej wersji API, dlatego niekoniecznie jest sens mieć wspólne kontrakty.‎

@shagrin - teoretycznie można... Tylko to moim zdaniem też nie jest rozwiązanie zbyt komfortowe. Mamy 3 projekty jako 3 mikroserwisy. Tworzymy czwarty projekt dla klas modelowych i dodajemy każdemu z nich zależność. Co jeśli mikroserwis A i C potrzebuje dodatkowo jeszcze jakieś klasy, a mikroserwis B nie? Wówczas należy dodać te klasy do tego czwartego pakietu przez co mikroserwis B dostaje dostęp do klas do których dostępu mieć nie powinien? Czy może tworzymy kolejny projekt dla udostępnienia określonych klas serwisowi A i C?
Albo mamy zbyt duży dostep, albo tworzy nam się jakieś dziwne rozbudowane drzewo zależności.

@somekind - Okej ale w naszym przypadku jest tak że wszystko jest wykonane w tej samej technologii (czy dobrze czy nie to już nie mi oceniać). Pytanie więc w jaki sposób do tego podejść?

eL napisał(a):

Tworzymy czwarty projekt dla klas modelowych i dodajemy każdemu z nich zależność. Co jeśli mikroserwis A i C potrzebuje dodatkowo jeszcze jakieś klasy, a mikroserwis B nie? Wówczas należy dodać te klasy do tego czwartego pakietu przez co mikroserwis B dostaje dostęp do klas do których dostępu mieć nie powinien? Czy może tworzymy kolejny projekt dla udostępnienia określonych klas serwisowi A i C?

Logiczne byłyby oddzielne kontrakty dla każdego mikroserwisu.‎
‎

Pytanie więc w jaki sposób do tego podejść?

A czy fakt, że to mikroserwisy cokolwiek tutaj zmienia? Jak byś zrobił w przypadku zwykłych serwisów?‎
‎

Cóż, na tym polega idea mikroserwisów, a także idea obiektów domenowych znajdujących się w różnych bounded contextach, pomimo że są to dokładnie te same klasy co do literki, to każdy kontekst/mikroserwis musi mieć ich oddzielny egzemplarz.

Mikroserwisy nie są dla wszystkich, czasami niektórzy wybierają bardziej pragmatyczne podejście i zamiast w architekturę zorientowaną na mikroserwisy idą w architekturę zorientowaną na serwisy (brak prefiksu a sporo zmienia ;P) . Architektura zorientowana na serwisy dopuszcza współdzielenie zależności między serwisami.

eL napisał(a):

Cześć.
Mam pytanie dotyczące mikroserwisów. Pracuję od niedawna w Niemczech gdzie trafiłem do stosunkowo nowego projektu.

Pracujesz u Niemców i wydaje cie się, że wasza architektura jest głupia :-)

Mikroserwisy to taka moda - ale pytanie ilu was tam jest? Bo jak piszecie w piątke te mikroserwisy to współczuję (już to widziałem).
Izolacja interfejsów i duplikacja ma sens - ale dopiero od pewnej skali (gdzie ilość updatów i problemów związana ze zmianami w interfejsach
przewyższa poziom złości związany z duplikowaniem kodu).

Ale jak jest was kilku- nastu. Piszecie kilka serwisów. Wszystkie w tej samej technologii. I od razu sobie rzucacie kłody pod nogi.... no cóż - ofiary mody: