Kiedy w mikroserwisach buduje się parent project?

Przykładem jest tutaj ten projekt.
https://github.com/mguenther/spring-kafka-event-sourcing-sampler

1. Kiedy otoczyć, mikroserwisy nadrzędnym pom.xml i wewnątrz niego zdefiniować pojedyncze moduły. W jakim celu się to robi?

2. Zauważyłem także, że jest nad wszystkimi mikroserwisami jest uber branch, który wszystko spina. W sumie spoko opcja, bo potrafi doprowadzić do porządku wszystkie mikroserwisy, ale z kolei to przypomina monolit.

3. Z kolei mikroserwisy powinny być niezależne, więc po co tutaj zależność od nadrzędnego pom.xml

Dzięki za odpowiedź

janek_sawicki napisał(a):

3. Z kolei mikroserwisy powinny być niezależne, więc po co tutaj zależność od nadrzędnego pom.xml

Nie jestem Architektem, ale mam swoją teorię na ten temat. Otóż prawilne, w 100% niezależne mikroserwisy wyglądają świetnie w teorii. Nie umiemy znaleźć 100 deweloperów Javy do 10 zespołów? Nie ma problemu zatrudnimy po 10 dewepolerów z 10 różnych technologii i niech każdy zespół pisze w swojej technologii. Przecież mamy mikroserwisy, a mikroserwisy są poliglot (cokolwiek to znaczy). Jednak ta idea upadła bo prowadziła do problemów komunikacyjnych między zespołami i dużej duplikacji kodu.
W rezultacie teraz są promowane mikroserwisy 2.0, mikroserwisy w wersji Enterprise, które różnią się tylko wersją języka, wersją frameworku i innych bibliotek. Oraz jest duże parcie żeby wszystkie aktualnie rozwijanie mikroserwisy aktualizować na najwyższą wersję frameworka. W tym właśnie pomaga nadrzedny pom.xml

W skrócie - niezależność na poziomie kodu nie jest tym samym co niezależność na poziomie strukturalnym.

Monolity to duży zbiór kodu, który musi działać na tej samej maszynie. Mikroserwisy to pojedyncze kawałki kodu, które działają na niezależnych maszynach. Organizacja kodu powinna ten model wspomagać, ale nie oznacza, że każdy moduł musi być niezależny.

Powstaje oczywiście pytanie - dlaczego nie pokusić się o całkowite pozbycie się zależności w kodzie? Odpowiedź - wygoda.

• parent pom.xml pozwala ci na trzymanie wersji zewnętrznych bibliotek w jednym pliku, a nie porozrzucanych w kilku plikach. Przykładowo - używanie różnej wersji kompilatora Apache Avro może zepsuć deploy
• czasami istnieją jakieś domenowe commonsy (np. jakiś egzotyczny encoding/decoding, zestaw klas biznesowych typu Person, Pesel itp. itd.) które warto po prostu mieć w wspólnym module, żeby nie rozsyłać maili typu "wyszły nowe commonsy, zupdate'ujcie się i sprawdźcie, czy nic się nie wysypuje")
• no i na koniec - moduły mogą być całkowicie niezależne, ale jednak połączone pom'em po to, żeby łatwiej się budowało i testowało

Czy to jest dobre podejście? Trudno powiedzieć, bardzo dużo zależy od tego jak powiązane są moduły. Kiedyś nie widziałem w tym problemu, teraz jednak wolę bardziej całkowitą separację, może z wyjątkiem pierwszego punktu.

wartek01 napisał(a):

parent pom.xml pozwala ci na trzymanie wersji zewnętrznych bibliotek w jednym pliku, a nie porozrzucanych w kilku plikach. Przykładowo - używanie różnej wersji kompilatora Apache Avro może zepsuć deploy

Problem ten można rozwiązać np poprzez Spring Cloud Config Server

W parent.pomie możesz trzymać jakieś infrastrukturalne rzeczy typu klient do service discovery, konfiguracja serwera, czy Springowe autokonfiguracje, żeby każdy zespół nie musiał stawiać wszystkiego od totalnego zera. Można to obejść dostarczając template usługi zawierający już ogarniętego poma, który można wdrożyć jako wersja 0.0.1. Ważne jest to, co chyba oczywiste, że pom ma znaczenie do momentu zreleasowania wersji, potem wszystkie zależności są już w paczce.