Tworzenie modularnego monolitu

Czy tworzenie aplikacji, która w warstwie prezentacji będzie wykorzystywała publiczne kontrakty danych modułów i je wywoływała in memory ma sens, jeżeli zakłada się ewentualność przejścia na mikroserwisy? Zakładam, że każdy moduł jest odseparowany w bazie danych i pobieranie danych z innych modułów jest tylko możliwe przez api danego modułu.

Czy takie moduły powinny się ze sobą komunikować? Jeżeli nie, to jak dostarczać potrzebne informacje do danych modułów? Może trzeba zapisywać potrzebne dane w kilku modułach np. utworzenie zasobu, który z poziomu zainteresowanych modułów nie jest taki sam, ale dla użytkownika ma 1 znaczenie w warstwie prezentacji.

Znacie jakieś projekty modularnych monolitów open source napisanych w javie lub c#? Przejrzałem przykładowe projekty z githuba devmentors, ale u nich każdy moduł tworzy akcje dla kontrolera.

Monolityczna aplikacja prowadzona przez moduły, i nie mam w tym nic "nie koszernego", i modularnych monolitów jest pełno od lat, i to są dobre programy w swoich obszarach

Zainteresowanie budzi "każdy moduł ma własną bazę", co jak odczytuję jako przeszczepienie idei mikroserwisowego modułu, co niekonicznie pochwalam. Np nadmierna granulacja bazy, która daje multum kłopotów i utrudnień, a niekoniecznie w takim przypadku coś w zamiast (niezależny development / dynamiczne hostowanie, gaszenie i podnoszenie uS)
Tak, o ile perspektywa rzeczywistego rozcięcia jest bliska i są to "ostatnie próby w monolicie", nie jeśli to overengineering z powodów ambicjonalnych, modowych czy :"wydaje mi się"

"To zależy" czy ta wycięta część bazy to 3 tabele, czy subsystem np jak w oprogramowaniu Magazyn & Handel / Ksiegowosć / Kadry (& Płace) / separowane Płace / Spedycja /CRM

Anatolijus napisał(a):

Czy tworzenie aplikacji, która w warstwie prezentacji będzie wykorzystywała publiczne kontrakty danych modułów

Co masz na myśli pisząc moduł? Bounded Context? Poddziedzina? Proces biznesowy?

Anatolijus napisał(a):

i je wywoływała in memory ma sens, jeżeli zakłada się ewentualność przejścia na mikroserwisy?

Co masz na myśli przez in memory? Coś jak MediatR?

Anatolijus napisał(a):

Zakładam, że każdy moduł jest odseparowany w bazie danych i pobieranie danych z innych modułów jest tylko możliwe przez api danego modułu.

Najlepiej za pomocą osobnych schematów baz danych.

Anatolijus napisał(a):

Czy takie moduły powinny się ze sobą komunikować?

Jak nie jak tak? Najlepiej asynchronicznie poprzez zdarzenia czy komendy. Czyli jak masz MediatR to moduł sprzedaż po zatwierdzeniu zamówienia, wysyła zdarzenie OrderApproved i zainteresowane moduły jak wysyłka, czy magazyn subskrybują sobie to zdarzenie i jak ono nastąpi, to wywołują swój proces biznesowy.

Anatolijus napisał(a):

Znacie jakieś projekty modularnych monolitów open source napisanych w javie lub c#?

Pierwsze co mi przychodzi do głowy to https://github.com/kgrzybek/modular-monolith-with-ddd

Anatolijus napisał(a):

ale u nich każdy moduł tworzy akcje dla kontrolera.

Nie widziałem kodu, ale dla mnie kontroler jest wyłącznie warstwą transportową i nie chciałbym, aby mój moduł biznesowy wiedział czego używam do obsługi żądań od aplikacji klienckich (desktop, http, CLI, soap). Więc jak mam akcję kontrolera ConfirmOrder to kontroler woła API mojego modułu biznesowego (interfejs, komenda) i wywołuje tym samym logikę biznesową. Moduł nie wie skąd przyszło żądanie bo i po co?

markone_dev napisał(a):

Anatolijus napisał(a):

Czy tworzenie aplikacji, która w warstwie prezentacji będzie wykorzystywała publiczne kontrakty danych modułów

Co masz na myśli pisząc moduł? Bounded Context? Poddziedzina? Proces biznesowy?

Bardzo ważne, a nie podniosłem tego w swojej wypowiedzi.
W jakim znaczeniu "moduł"

Moduł to u nas bardzo stare słowo, i ma wiele odcieni znaczeniowych (w tym w zderzeniu z monolit)

Z jakiejś książki wyniosłem podział na "T architekturę" i "M architekturę"
T (w przybliżeniu) oznacza techniczną (acz z niuasami), i moduły jakie sa pod względem technicznym
M w przybliżeniu marketingową - jak moduły sprzedajemy, jak piszemy instrukcje itd...

Obie literki w tej książce nie są nazwane explicite, autor pozwala się domyślić czytelnikowi, ja się domysliełm tak.

markone_dev napisał(a):

Anatolijus napisał(a):

Zakładam, że każdy moduł jest odseparowany w bazie danych i pobieranie danych z innych modułów jest tylko możliwe przez api danego modułu.

Najlepiej za pomocą osobnych schematów baz danych.

Być może tak.
Lub nie.

Na miarę odpowiedzi powyżej

markone_dev napisał(a):

Co masz na myśli pisząc moduł? Bounded Context? Poddziedzina? Proces biznesowy?

Bounded context.

markone_dev napisał(a):

Anatolijus napisał(a):

i je wywoływała in memory ma sens, jeżeli zakłada się ewentualność przejścia na mikroserwisy?

Co masz na myśli przez in memory? Coś jak MediatR?

Chodziło mi o direct call przez interfejs. Doznałem jakiegoś zwarcia w mózgu.

markone_dev napisał(a):

Anatolijus napisał(a):

Zakładam, że każdy moduł jest odseparowany w bazie danych i pobieranie danych z innych modułów jest tylko możliwe przez api danego modułu.

Najlepiej za pomocą osobnych schematów baz danych.

Tak. To jest coś o co mi chodziło.

markone_dev napisał(a):

Anatolijus napisał(a):

Czy takie moduły powinny się ze sobą komunikować?

Jak nie jak tak? Najlepiej asynchronicznie poprzez zdarzenia czy komendy. Czyli jak masz MediatR to moduł sprzedaż po zatwierdzeniu zamówienia, wysyła zdarzenie OrderApproved i zainteresowane moduły jak wysyłka, czy magazyn subskrybują sobie to zdarzenie i jak ono nastąpi, to wywołują swój proces biznesowy.

Czy informacje z eventu, który trafia do danego modułu możemy zapisać w jego lokalnej schemie?

Anatolijus napisał(a):

Czy formacje z eventu, który trafia do danego modułu możemy zapisać w jego lokalnej schemie?

Jeszcze jak! Docelowo chcesz przejść na mikroserwisy, gdzie każda usługa ma osobna bazę danych, i sobie do nich nie zaglądają. Tu ma być podobnie, nawet kosztem duplikacji danych.

Anatolijus napisał(a):

Chodziło mi o direct call przez interfejs. Doznałem jakiegoś zwarcia w mózgu.

Tak. Controller czy inny Presenter, może wywołać interfejs/fasadę modułu biznesowego, a może też wywołać komendę/query.

markone_dev napisał(a):

Tak. Controller czy inny Presenter, może wywołać interfejs/fasadę modułu biznesowego, a może też wywołać komendę/query.

Czy coś takiego jest poprawne?

public void Register()
{
  ...
  authModule.Register(...);
  shippingModule.AddUserDetails(...)
  ...
  transaction.Commit();
}

Anatolijus napisał(a):

Czy tworzenie aplikacji, która w warstwie prezentacji będzie wykorzystywała publiczne kontrakty danych modułów i je wywoływała in memory ma sens, jeżeli zakłada się ewentualność przejścia na mikroserwisy? Zakładam, że każdy moduł jest odseparowany w bazie danych i pobieranie danych z innych modułów jest tylko możliwe przez api danego modułu.

Czy takie moduły powinny się ze sobą komunikować? Jeżeli nie, to jak dostarczać potrzebne informacje do danych modułów? Może trzeba zapisywać potrzebne dane w kilku modułach np. utworzenie zasobu, który z poziomu zainteresowanych modułów nie jest taki sam, ale dla użytkownika ma 1 znaczenie w warstwie prezentacji.

Znacie jakieś projekty modularnych monolitów open source napisanych w javie lub c#? Przejrzałem przykładowe projekty z githuba devmentors, ale u nich każdy moduł tworzy akcje dla kontrolera.

Za bardzo kombinujesz. Zrób to najprościej jak się da.

Przepisanie na "mikroserwisy" (czyli pewnie 3 apki z http, a nie żadne mikroserwisy) to jest krok który się robi dopiero jak masz problemy ze skalowalnością, i jeśli nie jestes firmą pokroju netflixa, to ich nie potrzebujesz.

Anatolijus napisał(a):

markone_dev napisał(a):

Tak. Controller czy inny Presenter, może wywołać interfejs/fasadę modułu biznesowego, a może też wywołać komendę/query.

Czy coś takiego jest poprawne?

public void Register()
{
  ...
  authModule.Register(...);
  shippingModule.AddUserDetails(...)
  ...
  transaction.Commit();
}

Nie ma nic złego w posiadaniu metody Register która odpowiada za implementację procesu biznesowego. To co mnie niepokoi to jej implementacja którą wkleiłeś, a szczególnie obsługa błędów i sytuacji wyjątkowych, która przy odrobinę bardziej skomplikowanej logice będzie koszmarem. Generalnie w takich sytuacjach zamiast wywołań sekwencyjnych api modułów, stosuje się zdarzenia i process managery oparte o choreografię lub orkiestrację zdarzeń, aczkolwiek to zależy od konkretnego przypadku więc ciężko powiedzieć.