[Murasame]

W pracy chcieli sobie w końcu zrobić projekt na mikroserwisach. Ostatecznie wyszło średnio, dodam że wszystkie moduły działają na jednej bazie danych.

Generalnie układ jest taki, że mamy jeden moduł, który zawiera tam jakieś podstawowe funkcje, a reszta modułów korzysta z tego modułu (jest dependency w pom)

No i zaczynają się problemy, bo np. mamy jeden moduł przykładowo dla firmy A, drugi moduł dla firmy B. Mamy sytuację gdzie trzeba np. wygenerować raport z danymi zarówno firmy A jak i B, no i do którego modułu to wrzucić?
Albo np. mamy serwis z którego będą korzystać oba moduły i co, duplikowac kod? Parę razy chcieliśmy to wrzucić do tego podstawowego modułu ale odeszliśmy od tego, bo wyszłoby tak, że prawie wszystko byłoby w tym jednym module, w którym miały być takie podstawy jak encje, wysyłanie maili itd.

Pytanie czy to idzie jeszcze jakoś ogarnąć czy jest od samego początku kiepsko zaprojektowane?

Ps. Sorry jak coś głupio napisałem, ja mam zawsze problemy ze słownictwem jak trzeba gadac o jakiejś architekturze itd.

Czy może problem polega na tym, ze moduły są podzielone trochę jakby wedłud danych? Czyli załóżmy mamy firmę A, firmę B, dane pracowników itd. A może bardziej powinno to wyglądać tak, że mamy moduł od generowania raportów, moduł od wczytywania danych z plików itd.

#programowanie

[GeDox]

mamy jeden moduł przykładowo dla firmy A, drugi moduł dla firmy B. Mamy sytuację gdzie trzeba np. wygenerować raport z danymi zarówno firmy A jak i B, no i do którego modułu to wrzucić?

@Murasame: C

[whoru]

@Murasame: tworzenie nowego projektu od razu na mikroserwisach, no co mogło pójść nie tak? Ktokolwiek na to pozwolił powinien być #!$%@? z roboty.

[Murasame]

@whoru: A jak niby powinno się to robić? Obecnie próbujemy to tak ogarnąć, żeby nie skończyć z monolitem.

[zobq]

Czy może problem polega na tym, ze moduły są podzielone trochę jakby wedłud danych? Czyli załóżmy mamy firmę A, firmę B, dane pracowników itd. A może bardziej powinno to wyglądać tak, że mamy moduł od generowania raportów, moduł od wczytywania danych z plików itd.

@Murasame: imho jeśli wszystkie mikroserwisy pracują na tej samej bazie danych, to tutaj nie ma miejsca na mikroserwisy. Mikroserwisy powinny być jak najbardziej niezależne od siebie. Jeśli

[whoru]

@Murasame: modułowy monolit, kod pisać tak żeby dopiero potem móc to rozbić na mniejsze części (o ile to będzie w ogóle miało sens). Google: modular monolith. Tak to się kończy właśnie, ludzie nasłuchają się o mikroserwisach, nie mają kompletnie doświadczenia w DDD i potem kończą z ręką w nocniku, bo to przecież to samo co monolit tylko rozbity co nie ( ͡° ͜ʖ ͡°) Już pomijam fakt

[tylko_zerknalem]

@Murasame: Jeżeli jeszcze nie jest za późno, to po prostu przekształcie to co macie w dobrze zmodularyzowany monolit tak jak pisze kolega @whoru. Wyraźnie odseparowane od siebie bounded contexts, komunikacja tylko przez publiczne interfejsy, ukrywanie szczegółów implementacyjnych, sensowny podział pakietowy. I tak nie macie "czystej" architektury mikroserwisowej skoro wszystkie moduły uderzają do wspólnej bazy (która de facto staje się wtedy publicznym kontraktem między modułami).

Osobną kwestią jest to ile masz

[random_acc_vikop]

@Murasame: Ale macie jakiś biznesowy albo techniczny powód dla którego musicie mieć mikroserwisy? Czy tylko robicie to bo to jest "modne" teraz?

[fujiyama]

@Murasame: Podstawową zasadą jaką doradzam przy przejściu na mikroserwisy jest wydzielenie modułów technicznych:
np .wysyłanie poczty, raportowanie, szablony, generowanie PDF-ów, integracja z zewn. systemami, obsługa plików, uwierzytelnienie - no co tam jest w apce.
A sama logika biznesowa, procesy etc. nie sobie dalej pracują razem - wtedy nie ma dylematów do którego serwisu.
Potem dopiero można separować te dane, które nie mają powiązań lub np. są słownikami, wiązać wertykalnie serwisy, które

[Kresse]

@Murasame: Mirkoserwisy to się stawia, gdy pojawią się problemy, które mirkoserwisy rozwiązują (głównie skalowalność teamu lub poszczególnych komponentów systemu). Jeśli nie zaczynaliście z dużym teamem devów i złożoną domeną to ihmo bez sensu. Dobrze napisany monolit powinien dość łatwo dać się przerobić na mirkoserwisy - w takim idealnym, naiwnym przypadku wystarczy tylko wymienić fasadę danego modułu na jakiegoś klienta (np. HTTP). W praktyce trzeba jeszcze ogarnąć spójność danych i performance, co

[Murasame]

@Kresse: Dwóch devów jest nie licząc frontendu itd. xD I wydaje mi się, że te "pseudo-mikroserwisy" które mamy zaczynają powodowac więcej problemów niż korzyści.