e

nie udalo sie rozkrecic channela

;d

E tam, całkiem dobrze szło przez chwilę

Najwięcej aktywności od ho ho i trochę

Po prostu mało nas (do pieczenia chleba)

widze ze w offtopie piszecie zle rzeczy na microserwisy to nie rozmawiam z wami ;d

Ale taka prawda

Zaczynanie od mikroserwisów to proszenie się o kłopoty xD

Bo skąd masz wiedzieć jak rozdzielić rzeczy pomiędzy serwisy

Jak jeszcze nie znasz domeny wystarczająco dobrze?

jak dla mnie zaczynanie od monolitu to proszenie sie o klopoty bo jak juz sobie uswiadomisz ze cos zjebales to wszystko jest tak zaplatane ze i tak nic z tym nie zrobisz 😛 a tak na serio to mysle ze kwestia podejscia, obecnie dla mnie jakis mikroserwisy sie bardziej sprawdzaja. dziele sobie zawsze jakos funkcjonalnie ze kazdy ma robic jedna rzecz i przynajmniej mam w miare maly codebase w kazdym

no i sa dzieki temu ladnie odseparowane wiec ciezko czasami isc na skroty

Ale właśnie po to jest hexagon w monolicie

Bo taki typowe Railsowy spaghetti gunwokod

To jasne, to już po trzech miesiącach człowiek chce sie pociąć

Bo nagle jakiś bardzo inteligentny człowiek wsadził logikę do callbacku lifecyclowego modelu

Czy coś

Ale po prostu takie przedwczesne dzielenie aplikacji na sztywne kawałki

Jest dość złym pomysłem IMO

Bo trudno ocenić dobrą granulację a priori

Pół biedy jak zrobisz za duże serwisy, to idzie potem jakoś rozdzielić

Ale jak za małe?

Well, ups

A hexagon to trochę jak monolity tylko w jednym codebase

Piszesz odseparowany pure core

I te tzw. adaptery które komunikują go ze światem zewnętrznym

I potem jak już piszesz tą aplikację na tyle długo

Że widzisz jak się logicznie dzieli domena na części

To łatwo jest taki monolit pociąć wzdłuż tych interefejsów

Tyle teorii ; d

Jedyny przydatny przedmiot przez sześć lat studiów xD

no ale w mikroserwisach jak chcesz czesc zupdateowac to nie musisz calej apki ponownie deployowac tylko sobie jeden mikroserwis zmieniasz i spoko

Tego nie kwestionuję

Ale majac dwa egzemplarze monolitu i tak możesz zrobić już rolling release

Więc dla end usera wychodzi na to samo

plus kwestia gdzie sie ta aplikacja znajduje, bo wiadomo nie bede pisac mikroserwisow na desktopa, ale tutaj tez wole mocna separacje

ze np logika jest w osobnym libie i sie komunikuje tylko za pomoca eventow z gui

przecież to bez znaczenia czy masz monolit czy mikroserwisy. spaghetti da się zrobić i w jednym i drugim podejściu. to raz mikroserwisy można uruchomić na jednym jvm a monolit można rozproszyć

to dwa

ja nie czaję całe tej dyskusji co jest lepsze mikro czy mono

no ja sie troche smialem z tym pisaniem zlych rzeczy na mikroserwisy

ale fakt jest taki ze mi osobiscie akurat lepiej sie pracuje przy mikroserwisach

jezeli komus monolit bardziej pasuje to spoko, bic nie bede ;d

tak, na początku tak się wydaje że jest łątwiej

wiem ze sa pewne wady jak np deployowanie to masakra w porownaniu do monolitu (z reguly) albo dochodza kolejne problemy jak service discovery

i że możesz zrobić update tylko części systemu - to niby ma być zaleta

jak dla mnie tak, jak odkryje ze gdzies mialem jakis blad to nie musze wszystkiego deployowac ponownie. tylko sobie ubijam mikroserwis i szybko stawiam nowy

to jest plus

Ja generalnie nie mówię, że mikro są złe, tylko po prostu to nie jest dobry wybór na początek, jak jeszcze nie znasz dokładnie swojej domeny.

Ale jak już ją dość dobrze znasz, i twoja aplikacja jest już pewnej skali to na pewno ma to wiele zalet (vide Netflix).

no ale to i tak czy piszesz monolit czy mikroserwisy musisz sie wczesniej zastanowic nad domena rozbic na jakies funkcjonalnosci i wtedy zaczac klepac. i wydaje mi sie ze latwiej zmergowac 2 serwisy w jeden w systemie gdzie masz dosc luzne polaczenia niz w monolicie w ktorym latwiej (a przynajmniej dla mnie ;p) narobic zamieszanie i pracujesz nad jednym codebase'm.

w sumie brokernel jest troche takim monolitem @karol

ale hexagonalnym za razem i pisanym z mysla o tym, ze kiedys sie rozpadnie na mniejsze

tzn w sumie

cholera wie

no co komu pasuje. ja mam skrzywienie ze nawet apka desktopowa to tak naprawde 2 osobne czesci, ale nie mowie ze to jedyne sluszne podejscie tylko takie jakie mi obecnie najbardziej pasuje

Nie no, znaczy jasne że SRP, blah blah blah, ale wydaje mi sie że pewne rzeczy jest trudno ocenić a priori

I to nawet jak się już ma w tym doświadczenie

Każdy projekt jest jednak na swój sposób unikalny

Czytam tak sobie teraz DDD Evansa właśnie i są różne takie przykłady a propos rozumienia dziedziny i jak to może być niekoniecznie trywialne

Ja się zupełnie zgadzam z tym że taka separacja po bounded contextach jest jak najbardziej na rzeczy (Evans nawet miał prezentację na jakiejś konferencji ostatnio o mikroserwisach w kontekście DDD)

Tylko wydaje mi się że trzeba do niej dojść iteracyjnie od ogółu do szczegółu

A nie próbować zgadywać jak to zrobić zanim się ma o tym dobre pojęcie

I potem to jakoś łatać składając rzeczy do kupy

Ale to w moim wypadku takie dywagacje dość teoretyczne

Bo naczytałem się dużo

Ale nigdy nie miałem projektu o tej skali w łapkach

ja mam w sumie tendencje do implementacji rozproszonych analogow unixa chyba :d

no w unixie fajnie jest to zrobione, bo sie standaradowe programy ladnie komponuja

a co do designu od ogolu do szczegolu to calkiem spoko prezentacje widzialem ostatnio: https://www.youtube.com/watch?v=Tb823aqgX_0 o odwrotnym podejsciu

Jakby co to to jest ta prezka o której mówiłem - https://www.youtube.com/watch?v=yPvef9R3k-M

Ciekawa bardzo

za DDD bede sie musial zabrac w koncu

a prezki obadam zaraz ;d

no tez o DDD duzo slyszalem wiec sobie prezentacje obadam, ale kiedys pracowalem przy jednym systemie ktory podobno zalozenia DDD spelnial i to byla tragedia

ale zaprojektowana przez niemcow to tez nie ma co sie dziwic w sumie

Ja czytam ksiązkę Evansa ("Domain Driven Deisgn") i jest niezła

Jeszcze z takich "żelaznych pozycji" jest Vaughan, mam go w kolejce po tej

Generalnie nakierowane to dość mocno na obiektówkę jest

Ale wydaje mi się że w przeciwieństwie do deisgn patternów GoFa

Są to raczej dość uniwersalne rzeczy

w sumie tak jak sobie teraz o tym mysle

to u nas jakos doszlo do tego, ze chcemy ustalic “jezyk systemu” i pozostawic reszte kwestii kreatywnosci ownerow poszczegolnych modulow

No to brzmi trochę jak ubiquitous language

W jakiejś postaci

Wy macie o tyle prościej

Że sami jesteście swoimi ekspertami domenowymi

W sensie, rozumiecie czego potrzebujecie do testowania tych rzeczy na poteflonach

no, ale projekt rozpina sie w sumie na kilka takich wyraznych domen i one sie pokrywaja jakby z tym jak ludzie w biurze siedza 😄

A nie że przychodzi koleś i chce aplikację do zarządzani spedycją, a ty nie wiesz jak działają listy tranzytowe czy inne rzeczy

Które dla nich są oczywiste

to prawda

No i DDD jest teoretycznie właśnie do takich sytuacji stworzony

Tylko wymaga to też zaangażowania ze strony klienta

A dużo klientów myśli na zasadzie "ej dobra małpki, ja wam mówie zróbcie aplikacje, ale nie wytłumaczę wam jak, domyślajcie się"

It can't be handsfree

taa

czasami to nawet wystepuje wenatrzfirmowo

a najbardziej wkurzajace jest gdy ludzie maja pisac cos co jakistam projektant wyrysowal ale nie maja najmniejszego pojecia co to jest i po co i jest wieczny ping pong

na dzwiek UML dalej mi ciezko

Yea, Evans po tym jedzie właśnie

DDD to właśnie taka odpowiedź na to, że spoko analityk sobie przeanalizuje, może nawet dobrze

Ale jak nie ma informacji zwrotnej od programistów

wydaje mi sie ze generalnie podzial na analitykow/projektantow/programistow jest dosc sztuczny

To prędzej czy później ten pięknie zaprojektowany a priori model się rozjedzie z rzeczywistością

W obie strony - i implementacji i logiki biznesowej

jak kiedys pracowalem przy projekcie w domenie ktorej kompletnie nie znalem to mialem staly kontakt z klientem

i przynajmniej moglem sie szybko dopytac czy to co robie ma sens w ogole

wiadomo, ze projekty sa rozne itp ale mam wrazenie ze programisci pracuja zdecydowanie szybicej i lepiej jak maja dosc wolna reke 😜

No nie mogą mieć też za wolnej, bo zarządznie programistami to jak wypasanie kotów, ale tak - za duże ograniczenia śmierdzą.

No i Evans też to porusza, że każdy z programistów powinien być w jakimś stopniu analitykiem, a przynajmniej powinno być kilkuta takich którzy są dobrymi analitykami i programistami jednocześnie

Zeby próbować tą resztę kotów ogarnąć

znalazlem jakis DDD reference od niego i ma 62 strony to ogarne i sie wypowiem 😛

jak nam team podrosnie to bedziemy alokowac kolejne osoby pod skrzydla aktualnych ownerow roznych modulow i powinno byc cool ;d

Reference niby spoko, ale lepiej przeczytać całą ksiązkę jak będziesz miał czas

DDD/event sourcing/CQRS to rzeczy nad którymi trzeba trochę pomyśleć zanim zaskoczą