Wpis z mikrobloga

W jaki sposób dzielić aplikację na moduły (modularny monolit) lub mikroserwisy w optymalny sposób? Wiem, że jest to związane z bounded contextem czy domeną jak zwał, tak zwał, ale szukam konkretnych wskazówek i przykładów. Takie 2 głównie problemy jakie widzę, to raz, żeby nie skończyć z rozproszonymi monolitem czyli sytuacją kiedy każdy moduł/mikroserwis ściśle zależy od całej reszty i muszą być wdrażane jednocześnie, a 2 żeby też nie zrobić za dużych modułów/mikroserwisów, które ciężko ogarnąć i rozwijać. Jak to wyważyć? W ogóle czy jeden moduł/mikroserwis powinien ciągnąć dane z drugiego? Czy komunikacja synchroniczna nie powinna być opcjonalna i komponenty nie powinny się komunikować tylko eventami czy czymś podobnym?
#programowanie #naukaprogramowania #programista15k #mikroserwisy
  • 1
Nie ma złotej rady, czy idealnego granicy, dzieł tak i tak to bedzie dobrze. Bylem na szkoleniu DNA na kilku warsztatach z Sobótka, przeczytałem książkę która bardzo polecam
Learning Domain-Driven Design ta z małpką
Pracuje z kodem który jest bardzo poprawnie napisany (przyszedłem jak już był taki) jako modularny monolit.
Szkolenia i książka dużo mi daly, ale nie oznacza to że bez problemu teraz destyluje agregaty idealnie.