Fork me on GitHub
#clojure-poland
<
2016-02-10
>
nooga21:02:54

nie udalo sie rozkrecic channela

jaen21:02:06

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

jaen21:02:17

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

jaen21:02:32

Po prostu mało nas (do pieczenia chleba)

karol21:02:30

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

jaen21:02:42

Ale taka prawda

jaen21:02:53

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

jaen21:02:13

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

jaen21:02:20

Jak jeszcze nie znasz domeny wystarczająco dobrze?

karol22:02:59

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

karol22:02:09

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

jaen22:02:09

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

jaen22:02:20

Bo taki typowe Railsowy spaghetti gunwokod

jaen22:02:29

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

jaen22:02:58

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

jaen22:02:00

Czy coś

jaen22:02:25

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

jaen22:02:34

Jest dość złym pomysłem IMO

jaen22:02:40

Bo trudno ocenić dobrą granulację a priori

jaen22:02:52

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

jaen22:02:55

Ale jak za małe?

jaen22:02:58

Well, ups

jaen22:02:16

A hexagon to trochę jak monolity tylko w jednym codebase

jaen22:02:25

Piszesz odseparowany pure core

jaen22:02:37

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

jaen22:02:46

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

jaen22:02:53

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

jaen22:02:04

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

jaen22:02:10

Tyle teorii ; d

jaen22:02:23

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

karol22:02:38

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

jaen22:02:56

Tego nie kwestionuję

jaen22:02:08

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

jaen22:02:13

Więc dla end usera wychodzi na to samo

karol22:02:27

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

karol22:02:39

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

jan.zy22:02:40

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ć

jan.zy22:02:06

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

karol22:02:33

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

karol22:02:45

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

karol22:02:02

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

jan.zy22:02:07

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

karol22:02:43

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

jan.zy22:02:53

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

karol22:02:53

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

jan.zy22:02:04

to jest plus

jaen22:02:22

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.

jaen22:02:54

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

karol22:02:01

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.

nooga22:02:02

w sumie brokernel jest troche takim monolitem @karol

nooga22:02:38

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

nooga22:02:24

tzn w sumie

nooga22:02:28

cholera wie

karol22:02:19

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

jaen22:02:12

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

jaen22:02:19

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

jaen22:02:26

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

jaen22:02:55

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

jaen22:02:42

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)

jaen22:02:54

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

jaen22:02:06

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

jaen22:02:15

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

jaen22:02:25

Ale to w moim wypadku takie dywagacje dość teoretyczne

jaen22:02:29

Bo naczytałem się dużo

jaen22:02:39

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

nooga22:02:56

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

karol22:02:36

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

karol22:02:58

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

jaen22:02:37

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

jaen22:02:39

Ciekawa bardzo

nooga22:02:57

za DDD bede sie musial zabrac w koncu

nooga22:02:05

a prezki obadam zaraz ;d

karol22:02:03

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

karol22:02:11

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

jaen22:02:52

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

jaen22:02:09

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

jaen22:02:18

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

jaen22:02:29

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

jaen22:02:35

Są to raczej dość uniwersalne rzeczy

nooga22:02:56

w sumie tak jak sobie teraz o tym mysle

nooga22:02:59

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

jaen22:02:55

No to brzmi trochę jak ubiquitous language

jaen22:02:59

W jakiejś postaci

jaen22:02:33

Wy macie o tyle prościej

jaen22:02:43

Że sami jesteście swoimi ekspertami domenowymi

jaen22:02:55

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

nooga22:02:10

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

jaen22:02:25

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

jaen22:02:30

Które dla nich są oczywiste

nooga22:02:37

to prawda

jaen22:02:09

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

jaen22:02:18

Tylko wymaga to też zaangażowania ze strony klienta

jaen22:02:45

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ę"

jaen22:02:52

It can't be handsfree

nooga22:02:19

czasami to nawet wystepuje wenatrzfirmowo

nooga22:02:08

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

karol22:02:16

na dzwiek UML dalej mi ciezko

jaen22:02:18

Yea, Evans po tym jedzie właśnie

jaen22:02:38

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

jaen22:02:45

Ale jak nie ma informacji zwrotnej od programistów

karol22:02:59

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

jaen22:02:04

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

jaen22:02:13

W obie strony - i implementacji i logiki biznesowej

karol22:02:17

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

karol22:02:31

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

karol22:02:29

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

jaen22:02:54

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

jaen22:02:28

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

jaen22:02:35

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

karol23:02:27

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

nooga23:02:10

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

jaen23:02:49

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

jaen23:02:15

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