To jest 235. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o tym, jak dzięki Domain Driven Design zapanować nad chaosem w projekcie. 

Notatkę, linki oraz transkrypcję do dzisiejszego odcinka znajdziesz pod adresem porozmawiajmyoit.pl/235. 

Dzisiaj mam coś niezwykłego dla każdego programisty oraz architekta poszukującego nie tylko wiedzy, ale przede wszystkim unikalnego podejścia do nauki i rozwoju. Chciałbym przedstawić Ci szkolenie z Domain Driven Design, które jest absolutnie wyjątkowe na tle wszystkiego, co do tej pory mieliście okazję zobaczyć. Mowa o Domain Drivers autorstwa Sławka Sobótki oraz Kuby Pilimona, czyli osób, które wprowadzały to podejście w Polsce. Wydawcą, koordynatorem i jednocześnie gwarantem jakości szkolenia jest znany z takich hitów jak Droga Nowoczesnego Architekta, Legacy Fighter, Architektura na froncie czy Smart Testing Maciej Aniserowicz. 

Szkolenie to nie ogranicza się do teorii znanej z książek. Zamiast tego koncentruje się na praktycznym zastosowaniu technik, które leżą u podstaw tego podejścia. Co wyróżnia to szkolenie? Przede wszystkim metody dydaktyczne, których nie znajdziesz w żadnym innym kursie. Twórcy wykorzystują innowacyjne podejścia do nauczania, które sprawiają, że zrozumienie i przyswojenie wiedzy staje się znacznie łatwiejsze i bardziej intuicyjne. Będziesz miał okazję pracować na przykładach z dużej, realnej domeny, co jest rzadkością w standardowych szkoleniach. Przedsprzedaż Domain Drivers trwa tylko do 8 marca, a już teraz ponad 1000 osób zdecydowało się na jego zakup. Jeśli więc chcesz dołączyć do tego grona, odwiedź domaindrivers.pl i zapisz się już dziś. 

Śmiało mogę powiedzieć, że to nie jest zwykłe szkolenie. To inwestycja w rozwój Twoich umiejętności projektowania i implementacji oprogramowania, które przekładają się na realne korzyści w Twojej pracy. Nie przegap więc okazji i zaraz po przesłuchaniu tego odcinka odwiedź domaindrivers.pl. 

Podcast Porozmawiajmy o IT jest dostępny zupełnie za darmo. Obowiązuje tylko jedna zasada: Jeśli jesteś tu przynajmniej po raz drugi, to po pierwsze rozgość się, a po drugie odwdzięcz za te treści, wystawiając ocenę w Twojej aplikacji podcastowej lub polecając odcinek w social mediach. Dziękuję. 

Ja się nazywam Krzysztof Kempiński, moją misją jest poszerzanie horyzontów ludzi z branży IT, co realizuję m.in. poprzez ten podcast. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć, dzisiaj moimi gośćmi są Sławek Sobótka, właściciel firmy szkoleniowo-doradczej Bottega IT Minds, zrzeszający 70 ekspertów technicznych, inwestor i CTO kilku startupów. Hobbistycznie interesuje się psychologią pozytywną i kognitywistyką. Mentor w bestsellerowym szkoleniu Legacy Fighter oraz najnowszym Domain Drivers. Oraz Kuba Pilimon, niezależny konsultant, trener w Bottega IT Minds, wygłaszał przemówienia na licznych konferencjach programistycznych, prowadzi też własne szkolenia. Projektuje architekturę i wyciąga na prostą projekty pozornie skazane na porażkę. Po pracy oddaje się swoim dwóm hobby: kitesurfingowi oraz fizyce. Jeden z mentorów w bestsellerowych szkoleniach Droga Nowoczesnego Architekta i Legacy Fighter oraz wraz ze Sławkiem we wspomnianym już Domain Drivers. 

Sławek, Kuba, bardzo miło mi gościć Was w podcaście. 

 

SS: Nam również, cześć. 

JP: Cześć. 

 

Dzisiaj tutaj zaskoczenia pewnie nie będzie. Będziemy rozmawiać o Domain Driven Design, ale z takim akcentem i z takim nastawieniem, jak w praktyce wykorzystać to podejście i jak spróbować zapanować nad chaosem dzięki temu podejściu w projektach informatycznych, który to chaos tam często niestety występuje. 

Zaczniemy jednak klasycznie, czyli chciałbym Was zapytać, czy słuchacie podcastów. Jeśli tak, to może macie jakieś ciekawe audycje, które tutaj warto zarekomendować. 

 

SS: Wiesz co, ja generalnie nie słucham konkretnego podcastu, bardziej podążam za osobami. Z konkretnych to będzie Andy Huberman. Dużo od niego dowiaduję się o ludzkim ciele, o tym jak hakować ciało. Wprowadziłem sporo suplementów, w tym momencie już każdego poranka jest około 25 pigułek, które Huberman polecił. Nie wiem, czy to działa, ciężko powiedzieć. Jedna na pewno działa, to na 100%.

A poza tym lubię sobie podążać za Miłoszem Brzezińskim, Wolframem, ostatnio zaczął szaleć z fizyką kwantową i tego typu rzeczami, a ogólnie słucham YouTube’a, tak bym powiedział. YouTube tak dobrze mnie zna, powiem Ci, perfekcyjnie poleca to, co bym chciał z zakresu sztucznej inteligencji, fizyki, mechaniki. Swój wewnętrzny autyzm karmię codziennie oglądając i słuchając dużo o rzeczach, a trochę też o ludziach. 

 

Kuba, jak u Ciebie?

 

JP: Jest trochę podobnie z tym śledzeniem ludzi, ale jeżeli miałbym wymienić podcasty, które najczęściej gdzieś tam goszczą w moich słuchawkach, a właściwie głośnikach, bo ja to robię w samochodzie głównie, co jest błędem, nie polecam, bo nie można się skupić na dobrej treści, to też byłby Huberman  i Lex Friedman. Oczywiście oni produkują tyle contentu, że tego się nie da przejeść, przynajmniej ja nie potrafię tego przejeść. Tego jest zbyt dużo, to jest zbyt ciekawe. 

U Friedmana to są trzygodzinne, czterogodzinne odcinki przecież. Więc sobie wybieram te, właśnie tak jak Sławek powiedział, podążając za ludźmi, np. moje ostatnie odkrycie, tzn. nie moje, ktoś mi to polecił oczywiście, to jest taki typ, który się nazywa Joshua Bach. I on miał z Lexem chyba trzy odcinki. Mega autystyczny typ, ale warto go posłuchać. Po prostu typ ma odpowiedź na każde pytanie. Na każde. Z inżynierii, z kogniwistyki, z neuronauk, z różnych rzeczy. Na wszystko ma odpowiedź ten człowiek. Polecam go. 

On się wychował gdzieś tam w jakimś lesie za naszą zachodnią granicą, w Niemczech. Nie miał dostępu podobno do rówieśników, tylko cały czas czytał książki, bo rodzice byli chyba pisarzami albo kimś, to nie pamiętam już. On miał tylko książki w domu do rozrywki, czytał książki od dzieciaka. I teraz ma ciekawe przemyślenia. 

To są te dwa podcasty. Czasem jest taki gość, który się nazywa Sean Carroll, fizyk. Ciekawy podcast, nie wszystkie odcinki do mnie przemawiają, ale to znowu, jak trafi się fajny clickbaitowy tytuł, sobie włączę. A co do ludzi, których szukam w tych podcastach, to jak widzę, że pojawia się gdzieś np. Richard Dawkins, to rzucam wszystko. Nie ma nic ważniejszego. Trzeba tego typa posłuchać. Dukaja, a jeszcze z podcastów to już bardziej tak humorystycznie, chociaż nie tylko. Sam Harris  kiedyś nagrał taki podcast z Rickiem Gervaisem. 

Mają trzy sezony. One są za paywallem i to wbrew pozorom nie są tak głupie rozmowy. Oni zaczynają np. od odcinka, który brzmi Would You Rather? I tam masz pytania pod tytułem czy wolałbyś być człowiekiem z głową psa, czy psem z głową człowieka? I oni o tym 30 minut rozmawiają, ale to jest warstwowe. Tam są naprawdę ciekawe przemyślenia pod pozornie głupim pytaniem. Polecam. 

 

Myślę, Kuba, że chyba dużo jeździsz faktycznie, ale dzięki za te rekomendacje. 

Dobrze, słuchajcie, to do tematu. Myślę sobie, że jak pada to hasło Domain Driven Design, to każdy ma trochę inną definicję w głowie, bo pojęcie podejście jest dosyć szerokie, jest jakieś tam wspólne zrozumienie, ale właśnie co człowiek to definicja. Jestem ciekawy, jaką definicję Wy tutaj macie odnośnie DDD, czym według Was to podejście jest, czym nie jest, czy jest ważne w tworzeniu oprogramowania DDD? 

 

JP: Problem z definicjami w naszej branży jest taki, że my sobie wymyślamy jakieś pojęcie, które nie istnieje, a potem się o to pojęcie kłócimy. To jest taka obserwacja wieloletnia, że powstaje pojęcie, później się kłócimy, czy to jeszcze jest to, czy nie to. I teraz istnieją przynajmniej trzy definicje DDD, które można zauważyć w naszym świecie. 

Pierwsza to jest ta Evansowa, czyli oryginalna, to Main-Driven Design. Dużymi literkami można to nazwać. To jest akronim z jego książki, tam jest dużymi literami to nazwane. Później małe ddd, czyli wytwarzasz oprogramowanie sterowane problemem biznesowym. To nie jest jakiś zbiór metodyk, tylko po prostu podejście, można powiedzieć, wynikające z pryncypiów, które były dużo wcześniej niż książka Evansa. I gdzieś tam nasza definicja, która rozszerza to, co mówi Evans i inni „wielcy prorocy” z przeszłości o jakieś nasze metodyki. To jest takie DDD w naszym stylu. 

I teraz, jak można to rozumieć w ogóle? Chyba jednym zdaniem, najistotniejszą częścią Domain Driven Design to jest to, że buduje jakąś taką świadomość programisty/ programistki w kontakcie z biznesem. To jest takie naoliwianie styku, można powiedzieć, biznesowego i technicznego. Tak jak olej właśnie działa w silniku, czyli mogę się tutaj pomylić, poprawcie mnie, jeżeli się mylę, usuwa odpady, nadaje lepkości, czyli usprawnia tę pracę po to, aby ten mechanizm cały mógł współpracować na dłuższą metę. 

SS: To też, co powiedział Kuba, definicje zależą od poziomu dojrzałości albo co jest słabe, każdy jakieś prywatne wytwarza sobie. Przecież jest chłop, żyje. Eric Evans w Denver sobie żyje, można później go zapytać. Ale nie, ludzie sobie jakieś swoje wytwarzają, nie wiedzieć czemu. 

To, co powiedział Kuba, my rozszerzamy o praktyki, które uzupełniają na poziomie wytwórczym, żeby szybciej pewne decyzje podejmować, żeby umieć się odnaleźć w konkretnej sytuacji. To jeszcze o tym pewnie pogadamy tylko w praktykach, ale to, co mógłbym powiedzieć, część ludzi zadaje pytanie typu, czy DDD da się robić w jakimś konkretnym języku programowania. Albo czy da się go robić na frontendzie, albo na mobile’u? I wiesz… Są takie pytania, które jeżeli zadajesz, znaczy, że nie jesteś gotowy jeszcze na przyjęcie odpowiedzi. Np., czy do Lamborghini Huracan Evo da się włożyć instalację gazową? Może to być ciekawe, inżynieryjne pytanie, ale odpowiedź jest taka, nie kupuj Lamborghini, nie stać się po prostu. Jeżeli chcesz nam włożyć gaz, to nie, to nie jest Twoje pytanie zupełnie. 

Jeżeli zdefiniujemy, czym jest model, model zupełnie niezależny od technologii, a na koniec jeżeli stworzę sobie model danej dziedziny, bo w DDD masz dwa poziomy. Poziom strategiczny, czyli dzielę sobie problem na mniejsze problemy. I dla każdego z tych problemów tworzę osobne modele, dlatego że jednym modelem nie jestem w stanie rozwiązać, albo inaczej, jestem w stanie rozwiązać, być może wiele problemów, ale bardzo w sposób kłopotliwy i na opak, więc odnajduję w świecie rzeczywistym osobne problemy i dla każdego tworzę sobie osobne modele. 

I teraz, co to jest ten model? Model to jest coś, co mogę sobie zaimplementować na wiele sposobów, w dowolnym języku programowania. Może nie w każdym albo w niektórych będzie trudniej. Mogę go zaimplementować w Excelu, mogę go zaimplementować na kartce i rozwiązać problem długopisem na kartce, ale robię to poprzez język promowania, bo komputer robi to szybciej i sprawniej. Więc takie pytanie, czy da się zrobić w jakimś języku? No to nie, to jeszcze jest daleko do, w ogóle nie myślimy pojęciem modelu tutaj. 

I teraz tak, czym może być taki model? Możemy podać, może Kuba przykład z naszego systemu, który jest przykładowy, ilustruje całą wiedzę teoretyczną w naszym szkoleniu Domain Drivers. Co Wy na to, żebyśmy weszli w to trochę głębiej? 

JP: No pewnie, tam miałbym wiele różnych autonomicznych takich modeli właśnie. 

SS: Tak, bo system służy do tego, żeby zarządzać projektami. Ale wiecie, nie na takim poziomie, że mamy jakieś taski, coś typu Jira itd. Nie, chodzi o to, że system automatycznie podejmuje decyzję, zatrzymajmy ten projekt, bo tracimy na nim tak dużo pieniędzy, że lepiej zapłacić karę umowną, przenieść te koparki, tych ludzi, to wszystko na jakiś inny plac budowy i tam sobie zrobimy więcej. On podejmuje taką decyzję. 

I teraz, żeby ją podjąć, no to musisz stworzyć plan tego projektu, taki wykres gantta, najpierw kopiemy doły, później wlewamy beton, później coś tam robimy, albo najpierw piszemy kodzik, później testujemy, a później coś tam jeszcze jednak wgrywamy na rakietę, to sobie leci, tam dalej testujemy. Różnego rodzaju projekty, branża nie ma żadnego znaczenia. 

I to jest relacja przyczynowo-skutkowa. Jak zrobisz coś, to dopiero później masz prawo robić coś. Albo wiele rzeczy spotyka się w jednym punkcie. Muszę zrobić wiele rzeczy, żebym mógł np. namalować pasy na autostradzie. Wiele równoległych rzeczy musi się wykonać. I tutaj modelem czegoś takiego jest np. kalendarzyk. Mam w kalendarzyku zaznaczone dni i ja tutaj przez te 3 dni będę sobie kopał doły. Przez te 8 dni będę sobie tam lał beton, a później jak to zrobię, to sobie przez tyle dni będę lał asfalt. Nie wiem, czy ja nie bredzę teraz, bo nie mam pojęcia, jak się robią autostrady, ale wiecie. 

JP: Załóżmy, że tak to może wyglądać. 

 

Chyba jednym zdaniem, najistotniejszą częścią Domain Driven Design to jest to, że buduje jakąś taką świadomość programisty/ programistki w kontakcie z biznesem. To jest takie naoliwianie styku, można powiedzieć, biznesowego i technicznego. Tak jak olej właśnie działa w silniku, czyli mogę się tutaj pomylić, poprawcie mnie, jeżeli się mylę, usuwa odpady, nadaje lepkości, czyli usprawnia tę pracę po to, aby ten mechanizm cały mógł współpracować na dłuższą metę.

 

Brzmi sensownie. 

 

SS: Kalendarzyk jest jakimś modelem.  I teraz, uwaga, on jest bardzo fajny, żeby patrzeć na projekt. On jest wygodny. Tak byśmy zrobili makiety ekranów. Patrzę poprzez pryzmat kalendarzyka. Kalendarzyk to jest moja kontrolka w interfejsie i sobie coś tam robimy. Ale gdybyś chciał sobie odpowiedzieć na pytanie, co jest wąskim gardłem. Czy który element, jak się sypnie, to sypie nimi się cała budowa? Albo czy mogę to wąskie gardło zabezpieczyć tak, że mogę na inne sposoby tam dojść, ominąć ten problem, bo nie wiem, spadnie deszcz i ja nie zrobię tego elementu, nie wykopię gdzieś tam dołku na rurę jakąś tam, bo jest błoto, bo koparka mnie wiedzie, bo coś tam. Czy mogę jakoś inaczej rozwiązać problem pod tytułem odprowadzenie wody z jakiejś odcinki autostrady? 

No to już patrząc na kalendarzyk, nie wiem, no być może by się dało, tak? Trzeba w głowie zmieścić tysiące tych elementów, które składały się na budowę i wtedy jakoś to rozkminić. Ale gdybyś tylko użył modelu grafu, tutaj dla osób nietechnicznych, słuchajcie, graf to jest, jakbyście spojrzeli sobie na mapę taką, mapę drogową, no to macie miasta, takie kropki i między nimi kreski, czyli drogi. Czyli graf to są takie kropki połączone kreskami. To wygląda jak taka pajęczyna. Jeżeli sobie tak popatrzymy na problem tych etapów, to wtedy mamy masę algorytmów grafowych, które mówią, jak ominąć daną kropkę, czy dane miasto, bo mamy korek w danym punkcie na drodze, i mapa Wam omija korki, są do tego algorytmy, albo wykrywa ona wąskie gardła itd. 

Więc zmieniam model tego problemu na jakiś inny. Nie mówię, że on jest lepszy. On jest lepszy do tego problemu. Czyli widzicie, pojawia się nadrzędne pytanie, a jaki Ty masz problem? Uwaga, dla osób nietechnicznych teraz, jak inżynier mówi problem, to nie znaczy kłopot. Problem to jest zadanie do rozwiązania. Tak nas uczyli, tak brzmiało każde zadanie z fizyki, z matematyki gdzieś tam na drodze naszej edukacji. Jest taki problem postawiony. To nie znaczy kłopot. I teraz jak będziecie inżynierom zmieniać to słowo na wyzwanie, to się będą śmiali. Nauczyli się już w szkole miękkiej, żeby się nie śmiać, ale problem, czyli zadanie do wykonania. 

Czyli mam jakieś zadanie do wykonania i szukam pod to odpowiedniego modelu, bo w tym modelu mogę sobie po pierwsze łatwiej to rozwiązać, po drugie mogę zauważyć, że mogę dodatkowo rozwiązania zaproponować, czyli mogę do biznesu wyjść z propozycji: słuchajcie, wyście nawet nie myśleli, że moglibyśmy brać historyczne projekty budowy autostrady, szukać ich tych grafów, tych pajęczyn, i uczyć się, tu mamy nagle do czynienia z organizacją uczącą się, uczyć się tego, że jak typowo jest takie wąskie gardło, to można go obejść innymi ścieżkami, bo mamy tą wiedzę w organizacji, tylko tego nie wiedzieliśmy. 

Bo jak popatrzymy na kalendarzyki, to tego w kalendarzyku nie widać. Ale na innym modelu już będzie to widać. Czyli mam model i ten model tego grafu będzie świetny do tego problemu optymalizacji, np. wykonania jakichś etapów, czy zrównoleglania, co mogę równolegle kopać, a co nie mogę, muszę jeden na drugiego poczekać, ale będzie zupełnie słaby do np. wypożyczania koparek, wtedy ten kalendarzyk będzie lepszy. 

Więc mam różne modele, niby do tego samego problemu pod tytułem zarządzanie projektem budowy autostrady, ale w tym problemie odnajdujesz mniejsze podproblemy, to się tam nazywa poddziedziny, ale to już nie jest takie ważne, jak się nazywa. I dla każdej poddziedziny robimy sobie inny moduł, żeby był mi łatwiej i wygodniej. 

Jak tak spojrzysz na to, czym jest moduł, no to teraz pytanie, czy da się to zaimplementować w Pythonie, czy w JavaScript jest oczywiste. No pewnie w każdym języku się da. 

JP: Wszędzie można napisać graf. Niezależnie od tego, jaką technologię mamy. 

 

Jasne. Z tego, co mówicie, Kuba, Ty wspomniałeś, że DDD może być takim olejem, taką warstwą pośrednią pomiędzy zapleczem technicznym, a tzw. biznesem, bardzo uogólniając. Sławek tutaj mówił o modelu, który też leży gdzieś trochę pomiędzy, mam wrażenie, w sensie obydwa te światy go jakoś tam dotykają i jest dla nich ważny. Ale gdyby zapytać w zespołach takich, wiecie, produktowych czy projektowych o DDD, to pewnie raczej to właśnie programiści będą przynajmniej gdzieś kojarzyli to pojęcie, mam wrażenie. 

Jestem ciekawy, dlaczego tak jest i czy ta przydatność DDD jest faktycznie większa dla zespołów developerskich, czy może dla tych tzw. biznesowych, jak Wy to widzicie, jak Wy to tutaj upatrujecie? 

 

JP: Powiem jak, cytując klasyka, nie wiem, dlaczego to tak jest, mogę się domyślać, dlaczego tak jest i teraz snuję domysły, uwaga. Domain Driven Design, jak luźno przetłumaczę, to jest wytwarzanie oprogramowania sterowane problemem biznesowym, czyli zrozum problem/ wyzwanie biznesowe i zamodeluj je w ten sposób, żeby spełnić jakieś tam wymagania biznesowe, niebiznesowe, techniczne, funkcjonalne, niefunkcjonalne itd. 

I teraz jak się powie o tym odbiorcy stricte biznesowemu, czyli osobie nietechnicznej zazwyczaj, to jaka może być reakcja? To da się inaczej? Czy w ogóle, jaka jest alternatywa? To, co wy robiliście do tej pory, skoro teraz rozwiązujecie soft, rozumiejąc nasz problem biznesowy. Co robiliście wcześniej? 

SS: Bawiliście się z naszą kasę, skubańcy, okradaliście nas. 

JP: Chciałbym wiedzieć. Postawmy się w butach takiego odbiorcy. Nie wiem, czym jest DDD. Teraz tłumaczę, przychodzę do interesariusza biznesowego i mówię: Ej, byłem na konferencji, Sławek Sobótka opowiadał o tym, że jest coś takiego jak Domain Driven Design i to działa tak, że my rozumiemy ten wasz problem, gadamy z wami i później wytwarzamy soft, bo zrozumieliśmy, o co wam chodzi. Ej, róbmy to teraz, od teraz. 

Wyobraźmy sobie, jaka może być reakcja. No na Boga. Co robiliśmy wcześniej? Ja nie wiem, co robiliśmy wcześniej. Dlatego, to jest mój domysł, kończę go, że dlatego ta cała narracja DDD może nie pasować takiemu odbiorcy. Chyba że taki odbiorca faktycznie ma już bardzo, powiem poprawnie politycznie, bardzo nieprzyjemne doświadczenia z działem IT i on wie, albo ona wie, co oni faktycznie robili wcześniej, więc teraz się cieszę, że oni odkryli, że trzeba tak robić. Nie jest to nic odkrywczego dla tej osoby, ale cieszy się, że ktoś doszedł do podobnych wniosków, że jest ta wspólna płaszczyzna komunikacji, np. ten model, właściwie zazwyczaj ten model, o którym mówił Sławek. 

Uwaga, dodam tutaj, że ten model to nie musi być coś super złożonego. Tutaj w naszym przypadku był to graf. I też nie musi go rozumieć użytkownik tego systemu. Użytkownik faktycznie jako model może mieć ten kalendarz, a ekspert dziedzinowy może mieć jako model podobnego problemu graf. W zależności od tego, kto jest odbiorcą, mogę dopasowywać różny model, właściwie różną reprezentację tego samego modelu. 

Teraz programista też, czy programistka, dla nich to… Mówię dla nich, ale my też tam byliśmy, ja i Sławek. To było takie odkrywcze, że kurczę mogę inaczej pisać ten soft, dlatego że branża pokazywała w wielu miejscach, żeby robić to w bardziej naiwny sposób. Uwaga, celowo nie mówię prostszy, bo moim zdaniem to nie będzie prostsze, takie naiwne wytwarzanie softu na dłuższą metę, ale bardziej naiwny. 

Właśnie, czyli np. proceduralny kod wszędzie to nie jest zły kod, ale w niektórych aspektach będzie zły. Dla nas to było, mówię o branży i teraz osobach technicznych, jakiegoś, można powiedzieć, jakiegoś rodzaju odkrycie. W szczególności jak wyszła książka Evansa, to był  2003 r. To był przełom tysiąclecia, gdzie bardzo dużo kasy ładowało się w IT. Potrzeba było dużo więcej programistów, programistek, żeby ten soft wytwarzać, zaspokajać potrzeby, które się na rynku pojawiły. Mówiąc krótko, trzeba było szybciej kształcić kogoś, kto jest w stanie to robić. Więc poświęcało się jakość, że tak powiem, kształcenia i próg wymagań trochę spadał. 

Powstał profil pracownika, który był stworzony pod ten właśnie model, pod ten czas. Natomiast Evans opisał, jak to robili wcześniej. 

SS: Na narzędzia programistyczne zostało też pod to stworzone, czyli naiwnie patrzę sobie, widzę ten kalendarzyk na ekranie, dostałem makietę ekranu od UX Designera. Nie umiem modelować, bo nie byłem trenowany do tego nigdy w swoim życiu, robię sobie jeden do jednego encję, zapisuję do bazy danych, robię jakieś tam serwisik, mówiąc technicznym żargonem. Chodzi o to, że tak bardzo naiwnie to, co widzę na ekranie, przekładam sobie, to jest mój model mentalny tego problemu. Nie ma pod spodem żadnej wymiany, nie ma myślenia wieloma modelami i projekcjami ich na poziomie ekranów. 

I okej, w bardzo prostych systemach to jest perfekcyjne, idealne spojrzenie, ale trochę wylaliśmy dziecko z kąpielą, bo nie każdy problemik był prosty. Mieliśmy bańkę .com-ową, tak jak mówi Kuba w 2000 roku, prościutkie systemiki, gdzie GUI było prościutkie, a później zaczęliśmy robić w ten sam sposób te większe. To już się nie skaluje w ten sposób. 

JP: Właśnie. To, co powiedział Sławek, to jest super istotne, że to myślenie makietą nie zawsze jest złe. Dojrzały inżynier, świadomy programista/ świadoma programistka potrafi zrozumieć, jakie narzędzie dobiera do jakiego kontekstu. Narzędzie np. myślenia przez makiety będzie wspaniałym narzędziem w wielu miejscach systemu, ale w niektórych miejscach będzie po prostu strzałem w kolano. 

Jakbym mógł określić, czym jest DDD, to jest właśnie czymś takim. Dobieram klasę rozwiązania do klasy problemów, z jaką się mierzę akurat w danym miejscu systemu, tylko żeby zobaczyć, że w ogóle mam różne klasy problemów, to muszę znać różne klasy problemów i muszę nauczyć się, jak je dzielić. Większy problem na mniejsze problemy. Do tego mamy szereg naszych heurystyk, które gdzieś tam się pojawiają w internetach, w wielu miejscach. Mówię naszych, branżowych, ale też naszych, które sobie wytwarzamy wewnętrznie, które też nie są, nie chcę tutaj użyć słowa, że one są jakieś bardzo innowacyjne, są jakąś metaforą na to, co ludzie robili wcześniej. Metaforą, która widzimy, że działa, ponieważ szkolimy wiele osób, wchodzimy na audyty, robimy projekty ratunkowe. 

Jeżeli podam jakąś heurystykę, która wytwarzania oprogramowania, czyli w sposób taki, że działa na mniejsze, która wcześniej istniała, ale w inny sposób i nam to po prostu działa, to jej dalej używamy. Nie mówiąc, że jesteśmy twórcami tej heurystyki, bo tak po prostu nie jest. Prawdopodobnie Evans też nie był twórcą pomysłów, które opisał w książce, bo ludzie robili soft tak wcześniej. Polecam książkę Structure Design. To są chyba lata 78. Tak mi się wydaje. To są takie lata, czyli 20 lat przed awansem. Można mówić PE przed Evansem. 20 lat. 

I tam na tyle tej książki napisane jest: Wytwarzanie oprogramowania w nowoczesny sposób: dzielimy problem na mniejszy, strukturyzujemy sobie problem. 78 rok. Nowoczesne. I teraz uwaga. Jest jeszcze taki dopisek: No właściwie robimy to już 10 lat, ale nikt tego jeszcze nie opisał. W 1978 napisał gość, że robimy to już przynajmniej dekadę, ale jeszcze nikt tego nie opisał w jednym miejscu, więc ja to teraz opisałem. Świetna książka. 

Domain Driven Design, jak luźno przetłumaczę, to jest wytwarzanie oprogramowania sterowane problemem biznesowym, czyli zrozum problem/ wyzwanie biznesowe i zamodeluj je w ten sposób, żeby spełnić jakieś tam wymagania biznesowe, niebiznesowe, techniczne, funkcjonalne, niefunkcjonalne itd. 

I teraz jak się powie o tym odbiorcy stricte biznesowemu, czyli osobie nietechnicznej zazwyczaj, to jaka może być reakcja? To da się inaczej? Czy w ogóle, jaka jest alternatywa? To, co wy robiliście do tej pory, skoro teraz rozwiązujecie soft, rozumiejąc nasz problem biznesowy. Co robiliście wcześniej?

 

To słuchajcie, może spójrzmy na taką użyteczność tego podejścia, żeby to nie było tylko tak, że robimy jakąś tam sztukę dla sztuki albo według książki, bo tak zostało tam napisane. Na koniec dnia liczy się pragmatyczność tych rozwiązań. Spójrzmy na ten problem, który postawiliśmy sobie dzisiaj jako główny, czyli jak sobie radzić z chaosem w projektach dzięki właśnie DDD. 

Złożoność jest, myślę, jednym z takich elementów, które ten chaos nam generują. No można by się kłócić, czy to chaos generuje złożoność, czy może złożoność chaos, tak gdyby to jest wtórne. Chodzi mi o to, jak za pomocą właśnie DDD z tą złożonością sobie można poradzić. 

 

SS: Wiesz co, ja byłem na paru konferencjach w tamtym roku, gdzie stawiana teza, że Agile nie żyje, Agile nie działa, nie w sensie, że nie działa w ogóle, tylko nie spełnia obietnic i to, co świat… Ja się nie znam, od razu mówię, nie znam się na Agile. Aczkolwiek lubiłem go, zanim to jeszcze było modne, serio, bo mieliśmy taki bardzo światły zarząd w pierwszej firmie, gdzie pracowałem. I to było oczywiste, jak można inaczej, i czym tu się jarać, come on. Ale okazuje się, że dla kogoś, kto był jakby w korpotronie, to jest to przełom. 

I do czego zmierzam? Światli ludzie twierdzą, że okej, o ile już przez lata nauczyliśmy się, jak żeby Agile działał nam wewnątrz zespołu i to jest ogarnięte, to już działa, to cały czas mamy problem, żeby to robić pomiędzy zespołami. I teraz ludzie nietechniczni nie rozumieją, jaka to jest ta efemeryczna siła, która powoduje, że to wszystko jest tak posklejane, że jeden zespół czeka na drugi, a drugi na trzeci i wszystko się tak zamula i skąd się biorą te zależności. I jak już w ogóle dojdą, że ta efemeryczna niewiadoma siła ich tak spowalnia, to zaczynają stosować tzw. bullshido. I mówią tak: No to może przytulajmy się, albo musimy zwiększyć transparencję między zespołami, bo oni tak dużo ze sobą gadają, że jak będą jeszcze więcej gadać, to na pewno zaczną usuwać te bottlenecki i to splątanie. 

JP: Albo kartki trzeba stosować teraz kolorowe od dzisiaj. 

SS: Tak, tak. Jest dużo takiego bullshido, ale my jako inżynierowie patrzymy na to i widzimy, kurde, masz konesencję. Konesencja to jest może dwadzieścia rodzajów splątań architektonicznych, to widać. I teraz ten chaos, o którym mówisz, jest na dwóch poziomach. Wcześniej mówiliśmy o tym poziomie taktycznym, czyli mamy model np. tego kalendarzyka czy grafu i jeden albo drugi jest mniej chaotyczny, jest łatwiej, ale jest też poziom strategiczny, czyli to, co się dzieje pomiędzy zespołami. 

I mamy właśnie dwa poziomy DDD, strategiczny i taktyczny. Na poziomie strategicznym to, co jest najważniejsze, to stworzenie mapy w zależności pomiędzy tymi autonomicznymi modelami. Evan sobie to nazywał bounded contexty. Ta nazwa nie jest najszczęśliwsza, bo ona jest historycznie zakotwiczona w tamtych pewnych sposobach do projektowania dwadzieścia parę lat temu. Natomiast taka mapa unaocznia wszystkim, że zaraz, masz dwa prostokąty, widzimy, kto na kogo czeka, widzimy jakimi komunikatami się ktoś komunikuje. To jest tip dla osób nietechnicznych. 

Jeżeli Wasz architekt czy analityk narysuje prostokąty, które łączą się kreskami z jedną wielką belką, tam będzie napisane kawka, i pokazuje Wam piękny, modularny system, gdzie wszystko jest odseparowane, to jest bullshit. Dlatego, że to jest tzw. diagram statyczny. On nie pokazuje, jak system działa, gdy płynie przez niego prąd. On tylko pokazuje, gdzie będą kabelki między komputerkami, żeby one tam gadały ze sobą. Ale jak prześledzisz konkretne komunikaty, które idą po tych kreskach, to widzisz, że każdy z każdym rozmawia o wszystkim. 

A dalej, jak prześledzisz treść komunikatu i zajrzysz do środka i widzisz sobie, że jeden zespół drugiemu, czyli jeden moduł mówi drugiemu, czyli jeden mikroserwis mówi drugiemu: ej, zmienił się status klienta. No to co, jeżeli się zmieni w ogóle słownik statusów po stronie nadawcy, no to po stronie odbiorcy kodzik przestaje działać. Tamci muszą zmienić kodzik, gdy strona nadawcy zmieniła kodzik. I mamy już splątanie typów, konescencje. 

Bardzo prosta rzecz, ale już pokazuje, że oni razem na produkcję muszą wchodzić. A, drugi, trzeci, piąty, dziesiąty. Chyba nasz rekord, Kuba, na projekcie doradczym był taki, jak pamiętam, chyba nawet Ty byłeś na tym projekcie, że programista/ programistka musieli postawić na swoim laptopiku z aluminium zrobionym 30 środowisk dockerowych. Ale tam już RAM-u brakuje. 

JP: Więc trzeba było kupić lepsze maszyny. Bo tak jest, taka tzw. złożoność przypadkowa. Czyli muszę teraz kupić lepszą maszynę. Oczywiście to jest ekstremalny przykład, ponieważ tak zrobiliśmy rozwiązanie, że nie jestem w stanie używać czegoś innego. Nie jestem w stanie. To jest jakby złożoność dodana przez rozwiązanie, a nie wynikająca z esencji naszego problemu. Czyli w tym biznesie naprawdę nie działo się nic unikalnego. Nie było nic takiego, co by pod względem wydajnościowym, zmienności biznesowej, wolumetryki danych prowadziło nas do wniosku, że teraz potrzebuję takiego, a nie innego rozwiązania. 

SS: Ale to, co mówisz, jest bardzo ważne. Złożoność przypadkowa, czyli ta, która wynika z mojego podejścia, nieumiejętnego podejścia do rozwiązania. Ale mamy złożoność esencjonalną, która jest w biznesie zawarta i koniec, kropka. I teraz uwaga, ktoś może powiedzieć: O panie Sławku, pan się doedukuje, pan nie rozumie specyfiki branży, bo u nas to tak jest… U nas to tak jest, że tutaj w jednym module są te statusy, one się tak ciągle zmieniają i inni muszą reagować na te zmiany statusów. I co pan zrobisz? To taki biznes, to co pan jakieś takie bajki opowiada, że tego się da. 

Tak, da się to usunąć. Jest masa technik architektonicznych, tylko problem jest taki, że właśnie ludzie ich nie znają. Da się inaczej podzielić system na te prostokąty, zupełnie inaczej postawić granice, tak aby to, co jest zmienne, czyli w tym wypadku te statusy, wyciekały na zewnątrz. I powie: A jak mają nie wyciekać, jak jestem zainteresowany? Spokojnie, spokojnie, da się to, to się bardzo łatwo robi. 

Podpowiedź jest taka: popatrzcie, co my robimy jako branżunia? Rysujemy te prostokąty, w środku modelujemy struktury rzeczowników, tak, że zamówienie zawiera pozycję, a pozycja zawiera… Takie trywialne rzeczy. Następnie robimy CRUD-a  do tych trywialnych rzeczy, czyli create, read, update, delete, sobie edytujemy te dane, to jest trywialne, to mogą robić praktykanci, byłem praktykantem, robiłem. A później robimy te trudne rzeczy, czyli komunikację pomiędzy modułami i się martwimy: Oj, oj, oj, ale dużo komunikatów wycieka mi na zewnątrz. Oj, oj, oj, te komunikaty są niestabilne, bo mi się model wewnątrz prostokąta zmienia, więc ta niestabilność wycieka mi dookoła. Czyli mamy taką syjamską modularyzację, jak bliźnięta syjamskie. 

JP: Tak, dodałbym, że Sławek podzielił teraz ten proces na łatwe i trudne, tylko że ja jako inżynier nie wiem, czy to jest łatwe, czy trudne. Biorę po prostu pierwszą rzecz, która przychodzi mi do głowy, bo widzę też jeszcze wymagania często i gdybym jeszcze wiedział albo wiedziała, że te rzeczy późniejsze są faktycznie trudne, to może bym się zastanowił, czy robić to inaczej, ale to się wydaje wręcz prostsze, bo można powiedzieć, że ja zrobiłem prostokąty już i teraz muszę je już tylko połączyć. 

A na tym łączeniu właśnie wynika cała złożoność biznesu często i przez to, że wydaje mi się to proste, ten problem, który rozwiązuje za pomocą tego łączenia, tutaj ważna jest konstrukcja zdania: rozwiązuję problem za pomocą łączenia akurat, czyli buduję model, który akurat jest powiązaniem wielu innych tam kodzików, które wcześniej stworzyłem i wydaje mi się to naturalną techniką, bo stworzyłem już pojemniki, teraz je łączę. 

SS: Kuba, powiedz dowcip, czym się różni senior od juniora? 

JP: No właśnie, wbrew pozorom to nie jest dowcip, to jest samo życie. Czym się różni senior od juniora? Seniorowi znudziło się robienie joinów po tabelkach, więc robi teraz po mikroserwisach. Dodam jeszcze, że to, co Sławek też na to zwrócił uwagę, dlaczego mamy taki, a nie inny model? Dlaczego biznes mówi, albo biznes, albo osoba techniczna czasem, że u nas jest taka specyfika problemu? I okej, to nie jest ich wina, że tak mówią, ponieważ bardzo często ktoś tak zaprojektował system, dajmy na to 5 lat temu, odnieśliśmy ogromny sukces, przybyło nam klientów, przybyło nam ruchu, przybyło nam wymagań biznesowych, przybyło nam zmienności, przybyło nam pracowników, przybyło nam wszystkiego. I teraz rozwijamy dalej ten system. 

I ten prosty modelik, który na początku ktoś wymyślił, działał do jakiegoś miejsca. Ale nie zauważyliśmy tego punktu na osi czasu i dalej myślimy tym samym modelem, czyli innymi słowy, myślimy rozwiązaniem, które ktoś kiedyś zaproponował, być może miał lepszy lub gorszy dzień, a nie samym problemem. 

Tutaj przykład, o którym możemy mówić chyba nawet na pewno, z tego co pamiętam, najwyżej się wytnie. System do ładowarek elektrycznych. Byliśmy tam na akcji ratunkowej, ona chyba nadal trwa zresztą, tzn. to już nie jest akcja ratunkowa, no nieważne. I tam był taki problem, który brzmi następująco. Podjeżdżam do ładowarki samochodem, Teslą i chcę załadować sobie auto. I system musi odpowiedzieć na pytanie, czy Ty możesz załadować tutaj, czy nie. 

Jest bardzo wiele różnych czynników, które wpływają na to, czy możesz. bo jesteś klientem restauracji, która ma np. te ładowarki, to luz. Albo wykupiłeś na całą Europę, albo na Niemcy, albo na czymś tam, albo po prostu to jest sąsiada, który Ci pozwoli ładować i możesz. I to wszystko w systemie musi być jakoś rozwiązane i odpowiedź na pytanie, czy możesz ładować, musi tam paść. 

I był zaproponowany przez zespół, który był naszymi poprzednikami, taki wielki, ogromny graf, tzn. na początku nie był ogromny, hierarchiczny, który pokazywał, w którym miejscu jesteś w łańcuchu pokarmowym i pytanie było, czy mam prawo teraz załadować na tej ładowarce prąd. Było odpowiedziane za pomocą przejścia przez ten graf. To trwało 40 sekund chyba. W tym samym czasie na tym samym modelu leciały raporty, ale nie o tym. O czym chciałem powiedzieć, to o tym, że przychodziły nowe wymagania, my rozmawiając z tzw. biznesem, czyli ludźmi nietechnicznymi, oni nam mówili nowe wymagania w postaci grup w tych grafach itd. Czyli mówili językiem rozwiązania. Ten model już tak przesiąkł do tego biznesu, że oni nie potrafili myśleć w inny sposób. Tak, zostało to rozwiązane. 

Wtedy ukuliśmy pojęcie, jak ono było, odwrotne Domain Driven Design. Design Driven Domain, czyli za pomocą tego, jaki mam design, to będę teraz wymyślał, co mogę, czego nie mogę robić w sofcie. Powinno być na odwrót. I właśnie to jest chyba taki w złożonych systemach duży bloker. Myślenie statusami to wbrew pozorom jest uproszczenie tego samego problemu, o którym powiedziałem teraz. Myślę już o jakimś rozwiązaniem, że jest status w tym pudełku i muszę go jakoś tam skonsumować z innego pudełka. No nie, to jest sposób rozwiązania. Bardzo częste akurat za pomocą statusu i być może mam rację, ale jeżeli się utoruje na ten sposób myślenia, czyli rozwiązaniem, czy to tabelką, czy to konkretną kolumną, no to właśnie przy złożonych problemach będę miał później kłopot w tym, żeby rozwijać to oprogramowanie dalej. 

Kończąc tę wypowiedź, w tamtym systemie akurat trzeba było to zamodelować explicite, można powiedzieć. Czyli masz model, który odpowiada na pytanie, czy możesz ładować i takim akurat dosyć płaskim modelem to rozwiązaliśmy, który w kodzie, w komponencie konkretnym, pokazywał, że jest problem pod tytułem, czy możesz ładować, a nie jakaś tam grupa grafu, która modeluje 30 innych rzeczy. 

SS: Ten model grafu był bardzo dobry do innych problemów, ale nie do tego problemu, czy mogę, bo inne tzw. drivery się pojawiły, czyli chcieliśmy super szybko, żeby ładowarka komunikowała się z serwerem. To nie był dobry model, dlatego trzeba mieć kilka modeli. To jest trochę podobnie, jak projektujecie samochód. To na początku ładny samochód, jak się projektuje, zaczyna się od rzeźbienia go z gliny. Bo tylko wtedy ludzka ręka może kogoś dotknąć, pogładzić i powiedzieć, o ten kształt jest sexy, naprawdę jest fajny. Ten model nadaje się do tunelu aerodynamicznego, żeby sprawdzić aerodynamikę. Ma dwa zastosowania, ale nie nadaje się do crash testów. Inny model się używa w crash testach. 

Wtedy ukuliśmy pojęcie, jak ono było, odwrotne Domain Driven Design. Design Driven Domain, czyli za pomocą tego, jaki mam design, to będę teraz wymyślał, co mogę, czego nie mogę robić w sofcie. Powinno być na odwrót. I właśnie to jest chyba taki w złożonych systemach duży bloker. Myślenie statusami to wbrew pozorom jest uproszczenie tego samego problemu, o którym powiedziałem teraz. Myślę już o jakimś rozwiązaniem, że jest status w tym pudełku i muszę go jakoś tam skonsumować z innego pudełka. No nie, to jest sposób rozwiązania. Bardzo częste akurat za pomocą statusu i być może mam rację, ale jeżeli się utoruje na ten sposób myślenia, czyli rozwiązaniem, czy to tabelką, czy to konkretną kolumną, no to właśnie przy złożonych problemach będę miał później kłopot w tym, żeby rozwijać to oprogramowanie dalej.

 

Okej, czyli niewłaściwy model albo źle dobrany typ modelu, który później przekłada na to, że implementacja konkretnego rozwiązania może być pokraczna, powiedzmy. To jest jeden z takich problemów. Później pewnie stosowanie, to o czym Sławek tutaj mówił, stosowanie DDD w miejscach, gdzie niekoniecznie musimy się silić na takie rozwiązanie, gdzie stary dobry CRUD doskonale załatwiłby sprawę. Jakie jeszcze inne błędy są popełniane przez zespoły, które chcą się podjąć właśnie zaimplementowania, wdrożenia, zastosowania DDD w projekcie? 

 

JP: Odniósłbym się do tego, co już zostało poruszone, do tej mapy kontekstów, jak to nazywał Evans, albo mapy autonomicznych modeli, tak jak my sobie to nazywamy. Często jest tak, że już mam wiedzę na temat tego, że muszą być autonomiczne modele, I jakoś potrafię je destylować, ale potem popełniam błąd właśnie na łączeniu ich. Czyli który się, do którego dostosowuje. Jest wiele poziomów logicznych, odpowiedzi na pytanie, kto się do kogo dostosowuje. Przede wszystkim, kto rozumie czy język, kto konsumuje fizycznie, czyli komunikat, w którą stronę fizycznie lecą informacje, jakich narzędzi używam w styli architektonicznych. To są wszystko poziomy, można powiedzieć, integracji między modelami. 

I teraz tylko na takim właśnie artefakcie w postaci mapy autonomicznych modeli, ja mogę wykryć wszelkiego rodzaju patologie. Nie takie proste patologie typu zespół czeka na drugi zespół. Okej, to nie jest nic złego, jakby kryje taką patologię. Świetnie, ale mapa kontekstów pozwala na dużo więcej. Ona pozwoli mi zobaczyć np., że jeden zespół jest w tzw. relacji partnerstwa z czterema innymi zespołami. Czyli jest w takim, można powiedzieć, poligamicznym związku. I musi dostosowywać się, albo właściwie dogadywać się z wieloma różnymi partnerami i większość czasu takiego zespołu jest spędzana na Zoomie czy na czymś innym, a wcześniej to było w salkach konferencyjnych. Na spotkaniach. Dogadujemy się, co mamy zrobić. 

Albo jeszcze mniej widoczna patologia na pierwszy rzut oka, to jest taka, kiedy wydaje mi się, że ja rozwiązuję ten ważniejszy problem, to ludzie się do mnie mają dostosować i ja wytwarzam ewentualnie jakieś API na zamówienie. Czyli jestem w relacji dostawca –odbiorca. To się ładnie chyba nazywa customer-supplier. Nieistotne. Ale, mimo że jestem w tej relacji, czyli ja, można powiedzieć, trochę spełniam prośby, uwaga, prośby tych innych zespołów, czyli jednak ja mam słowo decyzyjne na sam koniec dnia, jak to mówimy na zachodzie, to jestem w takiej relacji z pięcioma zespołami. Czyli dostarczam pięciu różnym zespołom ich prośby. 

I teraz niby jestem dostawcą, ale w takim rozumieniu, że to jednak ja definiuję, jak to będzie wyglądało, ale robię to dla pięciu zespołów, czyli lokalnie można powiedzieć, że to jednak ja się muszę dostosować do reszty, ponieważ to, co ja robię, to z większością czasu spędzam z kolei priorytetyzując rozwiązanie, myśląc o tym, kto będzie pierwszy miał zapewnione API, a kto nie. 

Mogę oczywiście to naprawić, już nieważne jak, ale generalnie na to chciałbym zwrócić uwagę to, że super, że potrafimy szukać autonomicznych modeli, to jest bardzo ważna technika, ale równie ważna albo ważniejsza jest ta, żeby potem odpowiednio ze sobą połączyć. Czyli kto się do kogo dostosowuje, w jaki sposób itd. 

Kolejna rzecz, która często jest widziana i prowadzi do wszelkiego rodzaju patologii, to jest takie DDD w rozumieniu Domain Driven Development. Czyli mamy jakiś zbiór technik, mamy jakiś zbiór różnych wzorców i teraz będziemy to robić. Wymyśliliśmy, że to robimy i są dyskusje, które tak naprawdę mało wnoszą, można powiedzieć, pod tytułem, czy moja klasa, która reprezentuje mi tzw. agregat z DDD, może mieć adnotację ORM-a. 

Odpowiedź krótka: jak robisz je dobrze, to agregaty to nie ma to większego znaczenia, właściwie żadnego. Czyli wrzucamy się w jakiś dogmat i idziemy literalnie, można powiedzieć, z radami, które gdzieś tam krążą po internetach. My też tam byliśmy, żeby nie było. 

SS: Ale co ważne, w tym samym DDD Evans w żaden sposób nie wypowiadał się o adnotacjach, bo to jest nieistotne, natomiast ludzie sami sobie dodali, nie wiadomo skąd, takie dziwne przesądy. I co jest ważne, mówią: A bo to jest DDD, jak nie masz adnotacji, to wtedy to jest, albo jak masz. Nie! Skąd żeś to wziął, chłopie? Idź do Denver i Evans Ci powie, że to w ogóle jest agnostyczne. 

JP: Może dlatego, że on nie miał żadnej anotacji u siebie w książce, ale nie dlatego, że mówi, że są złe, tylko dlatego, że wtedy nie było ich jeszcze używanych w świecie akurat oprogramowania i technologii, której on używał w książce, czyli Java. Nie było tych ORM-ów tak popularnych jak teraz, więc pewnie dlatego ich nie użył. W kolejnej książce już są często na przykład. 

 

Zastanawiam się, czy w przypadku DDD od programisty nie wymaga się większej znajomości domeny, niż to jest w projektach, które tego podejścia nie stosują. Czy ta znajomość jest kluczowa? Czy trzeba ją odkrywać z tego punktu widzenia technicznego, albo czy to w czymś pomaga? 

 

SS: Krótka odpowiedź jest jasna, że tak, bo jak można inaczej? Jak mogę rozwiązywać problem, który, modelować problem, którego nie rozumiem, albo którego nie poznałem. I to jest taka książkowa, teoretyczna odpowiedź i tak wypadałoby odpowiedzieć na to pytanie. Ale jest szereg sytuacji, w których super, że wiem, że tak powinno się robić, ale z jakiegoś powodu mam ograniczenia, które powodują, że tak robić nie mogę. 

Przykładowo nie mam osoby, która mi przekaże te wymagania. Po prostu nie mam dostępu do tzw. biznesu, to może być ktokolwiek, kto po prostu jest ekspertem albo analitykiem, ktokolwiek, kto ma wiedzę. No nie mam dostępu. Albo mam dostęp, ale ta osoba z jakiegoś powodu nietechnicznego nie chce mi tych informacji dać, bo może jestem outsourcem i boją się utraty wiedzy, może tak być. 

Więc wtedy po pierwsze na pewnym poziomie dojrzałości widzisz kolejny biznes, modelując ten biznes jako architekt, programista/ programistka, więc widzisz pewnego rodzaju analogię do innego systemu. Widzisz, że na pewnym poziomie ogólności tak naprawdę, mimo że to jest inny biznes, to robią podobne rzeczy gdzieś tam pod spodem, więc możesz myśleć modelem, który wcześniej gdzieś tam stworzyłeś/ stworzyłaś. Oczywiście cząstkowym, niecałościowym. Gdzieś tam podobne klasy problemów można spotkać. Bo po prostu wiesz, że to jest kolejne przedsiębiorstwo, które w jakiś sposób zarabia pieniądze i wbrew pozorom nie różni się od tego poprzedniego. Za wyjątkiem sytuacji, kiedy robimy faktycznie coś mega unikalnego, to jest 1% przypadków pewnie, więc możesz użyć swojego doświadczenia z przeszłości. Oczywiście musisz jakoś je mieć. 

Teraz, żeby ta intuicja się zbudowała, to ona, wiadomo, sprzyja ludziom, którzy są w jakiś sposób zajęci projektowaniem, czyli widzieli różne projekty, eksponowali się na różnego rodzaju klasy problemów. Nie każdy ma taki, nie wiem, czy chcę użyć słowa przywilej, no nie każdy tak ma. Nie wiem, czy to jest przywilej, czy nie. Wtedy mogę z kolei eksponować się na to, co widzę w świecie takim rzeczywistym, jako użytkownik. 

Jeżeli jestem użytkownikiem, który ma zacięcie modelarza, to mogę myśleć. Wynajmuję sobie hulajnogę na 5 minut i myślę pod spodem, jakbym to zamodelował/ zamodelowała. Kupuję coś innego w internetach, zamawiam Ubera itd. Tych przykładów można mnożyć, bo technologia jest teraz po prostu wszędzie. 

I na pewnym poziomie ogólności mogę też zajrzeć do książki, która modeluje mi powtarzające się problemy, czyli książki o archetypach. To wszystko są przypadki, kiedy ja nie mam takiego bezpośredniego dostępu, nie mam takiej ekspozycji na osobę, która faktycznie, tak jak w książce ładnie jest napisane, że będzie mi wszystko o tym biznesie mówić. Ja mogę przeprowadzić warsztat, jeszcze najlepiej w kilka osób, gdzie mam rolę, rolę tego facylitatora spotkania, rolę modelarza i rolę eksperta. No nie zawsze tak mogę zrobić. 

Więc mamy wtedy triki na minimalizację czasu i na zbiór informacji, które są mi potrzebne, żeby zacząć modelować w jakikolwiek sposób, bo do czego chcę ja tak naprawdę dojść? Chcę dojść do jakiegoś pomysłu. Chcę mieć pierwszy pomysł na to, żeby zobaczyć, czy on ma sens. Na razie, jeżeli nie mam pomysłu, to takim trochę niebyciem modeluję. Dopiero mogę zacząć myśleć, czy moje rozwiązanie ma sens, jak jakiekolwiek rozwiązanie wygenerowałem. Ja chcę po prostu skrócić czas na generowanie czegokolwiek, żeby zacząć walidować, czy ten pomysł ma w ogóle dobry kierunek, czy nie. 

 

Myślę sobie, że część pewnie słuchaczy teraz myśli: okej, następny projekt, który będę startował, następny greenfield, to zrobię po Bożemu, tak zgodnie z tymi zasadami DDD i będzie pięknie. W praktyce wiemy, że gdy taki projekt startuje, to mało jeszcze wiemy o domenie i tak naprawdę okazuje się, że dopiero kiedy ta kupka błota istnieje, to mamy dużo większą wiedzę i przynajmniej potrafimy przewidzieć albo zrozumieć to poletko, w którym gdzieś tam się obracamy. 

Mimo wszystko pewnie dosyć często widzicie też sytuację pod tytułem mamy już projekt, który ma ustaloną architekturę, w której ta domena jakoś tam funkcjonuje i są jakieś powody, wskazówki ku temu, żeby spróbować to DDD zastosować. Jak do tego podejść? 

 

SS: Tutaj może dodam kontekst jeszcze, bo kiedy my wchodzimy na projekt doradczy, projekt ratunkowy można powiedzieć, to zespół, firma, przedsięwzięcie jest już dawno po takim etapie: Eee, może jeszcze damy radę. Już dawno jest po etapie: Co będziemy brać z tych darmozjadów, co jakaś ściema. Nie, nie, nie. Jeżeli podbicie minor version trwa 18 miesięcy, jeżeli masz regresję feature’ów, ujemne velocity, zwalnia Ci się większość załogi i masa problemów, konkurencja Cię wyprzedza, nie możesz ich gonić, to są momenty, gdzie się już nikt nie zastanawia, czy może, bo część słuchaczy powie: A po co mi to? Spokojnie, to może jeszcze, że tak powiem, musi skruszać organizacja czy projekt, musi skruszeć, dajcie im czas, jeszcze dwa lata. Zaciągniemy więcej mułu, trzeba będzie go bardziej odmulać. 

Ale chcę Ci podać kontekst. My mamy ten komfort, że jak wchodzimy, to nikt się nie pyta o takie rzeczy, czy ma to sens. Po prostu ból, ból jest ogromny. Biznesowy ból. 

JP: Druga rzecz, że ja nie pamiętam naprawdę projektu, w którym moim zadaniem było wprowadzenie DDD. A byłem na wielu akcjach ratunkowych, na wielu różnych audytach i naprawdę ciężko mi sobie przypomnieć, żeby tak był postawiony cel. Ponieważ takiego to nie jest cel nigdy. To nie jest cel. 

SS: Gdyby klient tak postawił cel, to byśmy go z tego błędu wyprowadzili. 

JP: Tak, pewnie to jest cel do czegoś innego. Najczęściej. Do nadrzędnego celu. 

SS: To jest narzędzie, którym możemy wyjąć elementy, bo DDD nie jest jakąś jedną wielką koparką. Tam masz około 50 różnych technik zebranych do jednego pudełka, bo Evans sobie tak to nazwał. I wyjmujesz to, co Ci jest potrzebne. 

JP: I to nas prowadzi do nadrzędnego wniosku, że pojawia się taka czasem narracja, jak na każdą technologię, metodykę: O, DDD to lek na całe zło. I się śmieją z tego ludzie, że lek na całe zło, jakby to wszystko miało rozwiązać. Nie. Ale nie ma leku na całe zło. 

SS: Nikt tego nie powiedział w ten sposób. Są to znowu prywatne jakieś urojenia. Nigdzie u Evansa to nie padło. Ani na żadnej konferencji. 

JP: Nie usprawni nam DDD problemu pod tytułem o, ludzie mają gierki dworskie, które uprawiają. Dyrektor po prostu robi kasę na boku, oszukując swoje przedsiębiorstwo. Okej, może uwypuklić technika z DDD, takie rzeczy, ale nie naprawi tego problemu. Nie naprawi tego problemu, że np. zespół techniczny jest wytrenowany do pewnego skilla i myślenie na przykład autonomicznymi modelami na razie nie jest ich kompetencją. Nie naprawi tego. I wielu innych rzeczy nie naprawi. 

 

Pewnie w wielu projektach by się takie narzędzie, takie podejście przydało. No właśnie, ale myślę, że to nas prowadzi tutaj do pytania, czy da się DDD zrobić częściowo albo tylko we fragmencie. Czy to nie jest tak, że jak już zaczniemy stosować jakieś techniki, jakieś podejścia związane z DDD, to oznacza to, że automatycznie musimy się całościowo przepiąć, że tak powiem, na ten sposób podejścia do wytwarzania oprogramowania?

 

SS: Nie, absolutnie, bo podejście strategiczne, czyli to, gdzie wykrajasz sobie elementy, nadajesz im ważność, określasz ich klasę złożoności, dobierasz skilla, ludzi, to i tak musisz zrobić. To po prostu nie musi się nazywać strategiczne DDD, po prostu dzielisz system na kawałki. Możesz go dzielić nieumiejętnie, ale i tak zawsze to robisz. Nadajesz im ważność 

Później wchodzimy w DDD tzw. taktyczne, które się typowo ludziom kojarzy z DDD, czyli te agregaciki i te rzeczy. I z doświadczenia powiemy, że każdy Wam to powie, który zrobił już kilkanaście projektów, że 5-7% kodziku pokrywa te obszary biznesowe, które są tak skomplikowane, że potrzebują tych tzw. głębokich modeli i tam sobie robimy to DDD taktyczne i te agregaciki, te wszystkie fajne rzeczy, aczkolwiek agregaciki nie zawsze mają sens, to są też domeny, gdzie zupełnie są bezstanowe i tego elementu konstrukcyjnego nie tworzymy. 

Więc podsumowując, to głębokie DDD robimy w core domain. Core to jest to, co daje Wam przewagę nad konkurencją, np. wizja projektu, na nim jest oparta 5-7% kodziku, A reszta nie. Nie, bo strategicznie podejmujemy decyzję, że to jest po prostu nieistotne. 

JP: Ja Wam powiem, że często mam taki niesmak, jak pada pytanie właśnie, czy robimy DDD, bo nie do końca wiem, co autorka pytania ma na myśli. Bo każdy ma coś innego na myśli. Innymi słowy, jaki jest mój papierek lakmusowy na to, żebym go przyłożył do projektu, który oceniam i jaka byłaby metryka, żebym ja powiedział, czy robię, czy nie. Niektórzy taką metrykę mają bardzo techniczną, czyli pewnie tymi wzorcami taktycznymi, o których powiedział Sławek. No nie wiem, masz tutaj pakiet taki, no to robisz DDD. Albo nie masz pakietu takiego, to nie robisz. Albo masz klasę, która ma, jeżeli to jest język obiektowy, to jest to obiekt faktycznie, czyli ma zachowania. To robisz. A jak nie, to nie robisz. 

SS: Bo dziedziczysz po base aggregate root. 

JP: Tak, dziedziczysz po base aggregate root. To robisz, a jak nie, to nie robisz. Masz adnotację, nie robisz itd. No nie. Przynajmniej w naszym rozumieniu to jest, można powiedzieć, dobieranie klasy rozwiązania do klasy problemu. I tyle. Czyli właśnie na poziomie strategicznym, czy ja to sobie nazwę strategicznym DDD, czy nie, ktoś to robi na pewno. Na poziomie taktycznym, jeżeli mam problem np. we współbieżnej rywalizacji o zasoby i rozwiązałem/ rozwiązałam go w jakiś sposób, to czy to nazwę sobie agregatem, czy nie, nie ma znaczenia. Co ma znaczenie, to że mam w kodzie coś, co rolę agregatu pełni. Czyli rozwiązałem jakąś klasę problemu. 

Mnie ciężko jest odpowiedzieć na to pytanie zazwyczaj, czy my robimy DDD, czy nie, bo w jakimś stopniu zawsze robimy DDD, bo to jest tylko skrzynka z narzędziami i zawsze jakiś element z tej skrzynki wyjmę, bo akurat potrzebuję, bo jest na tyle bogata, że ciężko mi o tym myśleć, ciężko mi myśleć o projektowaniu czegokolwiek bez jakiegoś narzędzia, które akurat w tej skrzynce też jest, ale być może pod inną nazwą. Wiele ludzi powie co innego. To nie jest takie pytanie z binarną odpowiedzią. Czy używasz Dockera? Łatwo odpowiedzieć na to pytanie, bo widzę, że gość albo pani używa Dockera, bo widzę, że odpala po prostu Dockera. Tutaj jest to dużo trudniejsze. 

SS: Ja się spotkałem kiedyś z zarzutem takiego seniora, który miał myślenie juniorskie: A widzisz, to jest wina DDD, bo nie da się określić, czy go używasz, bo w test driven development to ja wiem, czy robię test driven, czy nie robię, tak? A w domain driven to ja nie wiem. To słabe jest. No sorry, jeżeli coś się składa z kilkudziesięciu praktyk, które wzajemnie się wspierają i dobieram je zależnie od problemu, to właśnie dla nas to jest piękne, bo mogę sobie wybierać ze skrzynki z narzędziami elementy, które wzajemnie się wspierają, działają też osobno, ale dla kogoś, kto potrzebuje takich bardzo prostych wyjaśnień, bo jest tutaj, gdzie jest na swoim etapie kariery, to może najlepiej sobie niech nie zadaje takich pytań, bo niepotrzebnie się będzie męczyć. 

JP: Tak, to jest tak jakby zadać pytanie sobie: czy ja żyję zdrowo? Żyję, czy nie żyję zdrowo? 

 

Wiele się rzeczy na to składa. 

 

JP: Mnie się wydaje, że żyję, ale jak ktoś inny powie: Nie, nie żyjesz zdrowo. Co to znaczy żyć zdrowo? 

SS: No nie robisz sobie wlewów doodbytniczych, no to jak żyjesz zdrowo? 

JP: Nie robię sobie, dokładnie. 

 

Jak w ogóle jeszcze żyjesz? Dobrze, powiedzieliście, że domena jako taka nie ma tutaj znaczenia, nie determinuje, czy DDD może być użyte, czy nie, bo to nie jest jak gdyby zero-jedynkowa sytuacja, możemy użyć różnych narzędzi i niekoniecznie specyfika danej domeny wpływa na to, czy te narzędzia tam będą miały sens, czy nie. Czy jednak na podstawie tych różnych projektów, które widzieliście, w których gdzieś tam pomagaliście, czy możecie powiedzieć, czy są jakieś heurystyki, czy są jakieś czynniki, które powiedzą, że dany typ projektu, i tutaj rozumiem przez to wielkość, skalę, architekturę, bardziej się nadaje albo może inaczej, wyniesie więcej korzyści, jeśli tam zaimplementujemy, zaaplikujemy te właśnie narzędzia, a w innych to nie będzie miało sensu? Istnieją jakieś takie rozróżnienia? 

 

SS: Ja bym spojrzał na jeszcze inne wymiary, na przykład skalę czasu. Jeżeli mam za trzy miesiące dowieźć projekt, bo on mi ma wspierać kampanię reklamową na święta i potem ten kod idzie do śmietnika. To nie warto. Część osób myśli, że DDD strasznie dużo czasu spala, to może nie powiedzieliśmy, bo jak się widzi na konferencji, że masz rozwiązanie i ktoś pół godziny tłumaczy, jak do niego dojść, no bo to jest tryb dydaktyczny. W trybie dydaktycznym to wygląda, jakby długo trwało. Normalnie jest tak, że po prostu od razu masz ten pomysł,  bo myślisz pewnymi rozwiązaniami i masz heurystyki, które zawężają Ci stożek możliwości, czyli z kilkudziesięciu rozwiązań ja sobie zadaję parę pytań i w dwie, trzy minuty ja mam bardzo precyzyjnie wybrane rozwiązanie, więc to wcale nie trwa tak długo, jak to wygląda na prezentacjach. 

Ale nawet jeżeli kot idzie do śmietnika za trzy miesiące, to co to znaczy? Nie będę go rozwijał. Czyli moi ludzie nie będą tracić czasu na zrozumienie, co tam jest napisane. Moi ludzie nie będą popadać w jakieś wypalenie zawodowe czy depresję rzeźbiąc w rzadkim albo twardym czymś. Więc to nie jest mój problem. Czyli patrzyłbym na skalę czasu. 

Dalej patrzyłbym też na przewagę konkurencyjną. Czy jesteśmy organizacją, która buduje przewagę na tym, że się uczy. Bo ten model, o którym mówiliśmy, jest bazą wiedzy. My rozumiemy, że w naszej firmie to tak i tak się coś tam robi. I to jest pokazane w modelu, ale tym modelu nie w kodzie, tylko tym, który służy do komunikowania się z ludźmi nietechnicznymi. My gromadzimy tę wiedzę, robimy coś lepiej. Być może nie, wcale nie jesteśmy tego typu organizacją. 

I trzecia rzecz, w dużym systemie, czy nawet w średnim, tylko w małym kawałeczku będziemy robić tę taktykę tak głęboko, a całą resztę zrobimy, mówiąc wprost, byle jak, bo nie ma w tym żadnej wartości. 

JP: Tym takim procentem czy czterema procentami, to może być np. miejsce, gdzie jest dużo różnych osób zmieniających, mówiąc tak już bardzo technicznie, podobny stan. Czyli rywalizują o zasoby. I wtedy muszę w jakiś sposób zamodelować jednostki spójności, czyli akurat coś, co Evans nazwał sobie agregatami. 

A w innym miejscu mam np. złożoność obliczeń i zmienność obliczeń w czasie, ale też zmienność wymagań biznesowych co do tych obliczeń. Mam zupełnie inny problem. Obliczeniowy, transformacyjny można powiedzieć. I jeszcze mam zmienność tego, jak ta transformacja jest dokonywana. I w tych miejscach będę stosował jakieś rzeczy np. z taktycznego DDD. 

Tylko żeby w ogóle zobaczyć, że takie problemy osobne są odseparowane, to muszę zrobić jakąś analizę strategiczną. To się uzupełnia jedno z drugim. I będą miejsca, gdzie na jakimś poziomie dojrzałości, nie wiem, ja dostaję, powiedzmy, jakiś system i już wiem, z jakich modułów on powinien się składać, bo widziałem podobny, mam już na tyle dużo heurystyk i przykładów, że naprawdę z dużym prawdopodobieństwem trafię w rozwiązanie, a może być też sytuacja z drugiego ekstremum, że jestem już w podzielonym systemie, ja pracuję tylko w module X, dostaję wymagania tylko tam, to już nie mam czego tam dzielić, więc w ogóle nie będę robił tej części strategicznej, bo nie ma to sensu. Ktoś ją zrobił, czy to dobrze, czy źle, to jest inna sprawa, ale jest zrobiona i być może nawet nie ma miejsca na żadnego z tych elementów taktycznych, tam nie będę mógł użyć, ponieważ klasa problemów, którą się mierzę w tym miejscu, bo jestem na dole łańcucha pokarmowego, to wcale nie jest nic złego, wbrew pozorom, czyli dostaję małe klocki do rozwiązania, nie wymaga tego typu wzorców. 

 

Przywołujemy dzisiaj często książkę Evansa, bo wiadomo, to jest jednak biblia tego zagadnienia, ale tak jak Kuba wspomniał, Evans wiele rzeczy zapożyczył, podpatrzył, może użył już tego, co było tak naprawdę wcześniej gdzieś wykorzystywane w branży. Ładnie opisał, no właśnie. I zastanawiam się, jak to było przed albo może nawet i teraz, da się robić DDD bez tej wiedzy teoretycznej związanej z tymi zagadnieniami? Czy to według Was jest mimo wszystko taka rzecz abstrakcyjna, czy może raczej zdroworozsądkowa, do której da się dojść po prostu, widząc odpowiednio dużo problemów, sytuacji, rozwiązań? 

 

JP: Powiem tak, widziałem bardzo wielu programistów i programistek, którzy byli doskonali w swoim rzemiośle, ale nie wiedzieli, czym jest DDD. To myślę, że to odpowiada w jakiś sposób. I widziałem bardzo wielu programistów/ programistek, sam też prawdopodobnie podobny kod tworzyłem, którzy dobrze wiedzieli, czym jest DDD, a byli, że tak powiem, mniej doskonali niż ta pierwsza grupa. Ale wybrnąłem ładnie z tego zdania. 

SS: Też możemy powiedzieć, że pewne problemy istnieją po prostu w rzeczywistości i musisz je podjąć, rozwiązać i możesz dojść do tego rozwiązania po prostu na drodze logicznego rozumowania i sobie poradzić. Ale jak sobie patrzę na siebie właśnie z historii i na ludzi, których szkolimy przez 15 lat, to musicie pamiętać, lewa kora przedczołowa boczna, ta część tutaj na czułku, ona myśli symbolami werbalnymi, żeby opisać rzeczywistość. I ona myśli indukcyjnie, czyli jest jakby takim salonem lusterek. Jak jakiś promień wpadnie, to z niego nie wypadnie. Ona sobie buduje opis świata z tego, co zna. 

Teraz jeżeli jedyne sposoby modelowania rzeczywistości to jest serwis i encja, albo HashMapa HashMap, no to będzie mi bardzo trudno wyjść z tego pudełka i zauważyć, że mogę innymi elementami konstrukcyjnymi zamodelować problem, w ogóle wiedzieć, jakie klasy problemów istnieją. Bo tak byłem nauczony, oglądałem sobie tutoriale do frameworków. Musicie pamiętać, tutorial do frameworka jaki ma cel? Ma cel sprzedać Ci framework. Sprzedać, on jest za darmo. Nie jest za darmo. Jeżeli coś jest za darmo, to popatrz, gdzie jest cash flow. Kupujesz wsparcie, kupujesz szkolenia z frameworka itd. To jest jak dealer. Pierwsza działka gratis. Jak się wciągniesz, to będziemy dalej rozmawiać. 

Więc jeżeli jakiś framework pokazałby Ci: zobacz, tutaj masz tyle elementów konstrukcyjnych do rozwiązania tylu problemów, to sobie myślisz: Ojoj, ale to jest trudne, to do dupy jest ten framework, nie będę go używał, wezmę sobie ten prosty, który ma tylko serwis i encje, czy coś tam innego prostego. I rzucamy się na to gdzieś tam na koniec naszych studiów, bo chcemy iść do pracy i chcemy sobie pracować w danym frameworku, bo widzimy, że w tym zatrudniają i myślimy elementami tego frameworka, które, przypomnę, nie były stworzone ku temu, aby nimi rozwiązywać problemy, bo problemy są trywialne w tych tutorialach. 

One były do tego, żeby rozwiązywać problemy techniczne, obsługę requestu, bindowanie gdzieś tam danych z GUI-em, jakieś takie proste rzeczy techniczne, a problemik to był prościutki tam jakiś prosty sklepik itd. Więc jeżeli uczę się modelowania na podstawie tutoriali do frameworków technicznych, to nie za bardzo mam w głowie w ogóle wyobrażenie, jakie inne klasy problemów mogą istnieć na świecie i wtedy to jest normalne, że na wszystko patrzę przez pryzmat makiet ekranu, przez pryzmat jakichś tam encje i serwisu i takich rzeczy. I to jest okej, prawdopodobnie do większości w dużym systemie 90% problemów tak rozwiążesz. I to jest super, ale te 10%, te krowy, które są przewagą, to jest encja.

 

Czy DDD wobec tego ciągle się rozwija? Chodzi mi o to, czy na tym poziomie takim narzędziowym, metodycznym wszystko zostało już powiedziane i tylko stosujemy to podejście do realnych problemów, czy też nadal sama, nie wiem, czy to może nazwać metodologią, ale wiecie, o co mi chodzi, to podejście ewoluuje? 

 

SS: Ewolucja była bardzo mocna przez pierwsze kilka lat, gdzie Udi Dahan i Greg Young, dwie najważniejsze postacie moim zdaniem, to jeżeli chcielibyście dobrze spędzić czas, to moim zdaniem zróbmy sobie playlistę Grega Young, Udi’ego Dahana i dowiem się więcej niż jak miałem pojechać na jakąś konferencję i tam siedzieć i oglądać. Tych dwóch ludzi popchnęło bardzo mocno temat do przodu i oni akurat weszli w momencie, gdy dużej skali systemy pojawiały się na horyzoncie, bo Evans jest z czasów, kiedy wszystko było gdzieś tam monolitem, i to jeszcze nie była ta skala ruchu. Natomiast oni zaczęli coś takiego jak Distributed Domain Driven Design, 4D, i oni popchnęli mocno temat. 

Dalej, jak się ogląda współczesne prezentacje, to oni mocno się skupiają, tzn. nie mówię oni o Gregu i Udim, nie, nie, mówię nowe, nowe osoby, które jakby weszły do tej kasty proroków, tam za bardzo nowe rzeczy się nie pojawiają. Oni stanowią się nad definicjami, moim zdaniem niepotrzebnie, metodycznie szukają rozwiązań pewnych problemów, ale nieskromnie powiem, że my w Bottega IT Minds mamy chyba to dobrze ogarnięte przez te lata. Możemy, Kuba, chyba opowiedzieć o paru naszych heurystykach, technikach symulacji, gdzie mamy procedurę, którą możemy nauczyć i juniora i seniora nawet. Te kroki postępowania są dobrze sproceduralizowane, jak przejść z jednego artefaktu do drugiego. 

Przykładowo zbieramy sobie informacje. Do DDD zostało doklejone event storming, technika do zbierania informacji. Alberto Brandolini opracował storming na trzech poziomach, takim strategicznym, procesowym i taktycznym. I jak sobie z tych kolorowych karteczek teraz stworzyć mapę kontekstów? A jak w mapie kontekstów zrobić kolejne karteczki i znaleźć sobie, jak działa konkretny biznes i stworzyć modele? Więc tam jest cała masa procedur, które mówią, jak to masz zrobić po kolei, te procedury możemy na siebie nakładać, żeby one się wzajemnie potwierdzały. I to jest coś, z czego jesteśmy dumni, bo nikt tego tak, moim zdaniem, dobrze nie zrobił. 

Jeszcze raz powiem, nieskromnie to zabrzmi, ale no, no niestety, tak, jak się ogląda różne materiały, to no, wiesz, my mieliśmy taki rodzaj presji nałożonych na siebie, że dobra, zrobiliście coś tam na projekcie doradczym, fajnie, fajnie, wyjęliście jakby królika z kapelusza, fajna sztuczka, która się bierze z doświadczenia, z intuicji, a teraz nauczcie moich ludzi, żeby oni to samo robili. I przez wiele lat nie wiedzieliśmy, no jak, no to jakoś to wyszło, ale spokojnie, krok po kroku zaczęliśmy wzajemnie sobie dekomponować procesy myślowe, jak ty to robisz, jakie tutaj pytanie zadajesz, na to zwracasz uwagę, jak sobie wyobrażasz to, jaki masz model mentalny, jak sobie wymieniasz modele na inne mentalne, po to, żeby zauważyć pewne rzeczy, zadawać pytania. Więc tak, to mi się wydaje, było prywatnie duży krok dla nas. 

JP: To jest ciągle algorytm, czy procedura heurystyczna, warto zaznaczyć. Warto zaznaczyć, że ta dekompozycja nasza to jest ciągle heurystyka. Jak ktoś twierdzi, że da się to sformalizować w kroki i dojść do zawsze tego samego wyniku, który jest poprawny, odpowiem dyplomatycznie: nie widziałem takiego systemu i nie znam kogoś, kto by stworzył taki system. Wydaje mi się, że się nie da po prostu. 

Warto wpaść w dosyć szybki sposób w przestrzeń tych rozwiązań, gdzie jest wynik gdzieś tam optymalny, niekoniecznie idealny. Mówię o dekompozycji na mniejsze modele. Jeszcze dodam, po co w ogóle my tak prywatnie też dzielimy na te modele sobie problem. Dlaczego? Bo jeżeli ktoś potrafi zamodelować wielkie przedsiębiorstwo jednym modelem, sprytnym jakimś i faktycznie je kuma. Załóżmy taką sytuację, faktycznie kuma ten model i pracuje sobie sam, to jaka to musiała być ta osoba? Jakie musi mieć cechy, żeby ogromne przedsiębiorstwo sprytnie zamodelować jednym modelem, który pewnie będzie złożony, bo rozwiązuje wiele różnych problemów, zazwyczaj będzie złożony, to musi być ta osoba piekielnie, piekielnie inteligentna. Tak? Piekielnie. 

SS: IQ 160. 

JP: Tak. My takiego nie mamy. Nawet nie jesteśmy blisko. Więc po to, aby sobie ułatwić walkę z naszym ograniczeniem, jakie mamy, czyli z głupotą, dzielimy sobie problem na mniejsze problemy, bo jest łatwiej. Ponadto ja przynajmniej, nie wiem jak Sławek, ja jestem leniwy. Tak jest po prostu łatwiej. Nie dlatego, że tak mówi dogmat, tylko po prostu łatwiej mi się w ten sposób myśli o problemie i szybciej dochodzę do jakichś sensownych rozwiązań, a ponadto są inni ludzie w projekcie, którzy pewnie też tego IQ 160 nie mają, bo jednak to jest jakiś system, który tworzymy razem. I nawet jak ja bym to kumał, gdybym miał takie IQ, to są jeszcze inni. 

SS: To nie jest sztuka dla sztuki, bo nie ma artystów w naszej branży zbyt dużo. I to, co Kuba mówi, ja widziałem, obaj zresztą widzieliśmy, my byliśmy na projekcie, gdzie był człowiek, który miał takie IQ na około 160 i próbował rozwiązać gigantyczny problem. I wiecie, co się stało? Jego ludzie, dla których on te modele tworzył, odpadli dużo wcześniej, się pogubili w tym totalnie. Nie byli w stanie. I co z tego, że on sobie to zrobił, jak ludzie, którzy mieli to implementować, nie byli w stanie tego zrozumieć. 

My przyjeżdżamy na akcję rynkową i my też tego nie rozumiemy. I zauważyliśmy, że on się też pogubił w pewnym momencie. To jego IQ wielkie spodobało, że on się pogubił tylko później niż zespół. Ale też się pogubił. Po prostu. 

 

Tak, nikt nie jest doskonały. Myślę, że tutaj też rola intuicji może być znacząca. Ta intuicja taka raczej wynikająca z tego, że zobaczyło się już wiele i dzięki temu mniej więcej podobnie jak w szachach wie się, intuicyjnie się czuje, jaki ten krok następny, ruch następny zrobić. 

Tutaj opowiadacie o czymś takim jak szkolenia dla pracowników firm, których gdzieś tam, w których jesteście, pomagacie na tych projektach ratunkowych. To jest jak gdyby jedna rzecz, ale niedawno zdecydowaliście się tą wiedzą dzielić znacznie szerzej i śmiem powiedzieć, że prawie dla każdego, żeby faktycznie lepiej nam się na koniec dnia pracowało. Teraz pewnie jest dobry czas, dobry moment, żeby opowiedzieć krótko o Domain Drivers, Waszym nowym dziele, które jak będzie ten odcinek publikowany, będzie w okresie przedsprzedaży. Dlaczego zdecydowaliście się na taki krok i kto jest adresatem, kto najwięcej wyniesie z tego szkolenia?

 

SS: Dlaczego taki krok? Ten pomysł chodził nam po głowie od lat, ale czuliśmy, że jeszcze potrzebujemy sproceduralizować ostatnie kawałki, które były takie właśnie intuicyjne, a nie chcemy, żeby to było oparte na intuicji. Chcieliśmy się podzielić swoją intuicją, czyli wyjąć z głowy nasze wglądy, rozłożyć je na procedury, na drzewa decyzyjne, na co zwrócić uwagę, dlaczego zwrócić uwagę. 

Na tę potrzebę przygotowaliśmy specjalną formę wizualizacji tej wiedzy, którą kostkę trójwymiarową, na której widzisz, jak decyzje na jednej płaszczyźnie, czyli np. na płaszczyźnie strategicznej wpływają na decyzje architektoniczne, a te na implementacyjne. A jak problemy implementacyjne cofają Cię do architektury, gdzie musisz trochę inaczej zrobić i cofają Cię do biznesu, gdzie musisz być może zaproponować inne rozwiązanie po to, żeby było taniej i szybciej, więc mamy sekwencję decyzji, ale decyzje, które podejmujesz na różnych płaszczyznach czy wymiarach przedsięwzięcia. Tych wymiarów jest tam 10 różnych. I to jest jakby taki damp, core damp naszej intuicji. 

JP: Ja tak patrzę też na rodzaj i wektor pytań, które się pojawiają na przestrzeni ostatnich lat. W 2018 wydaliśmy z Kubą Kubryńskim, z Łukaszem Szydło, z Maciejem Aniserowiczem szkolenie DNA, Droga nowoczesnego architekta. Taki przegląd tego, co architekt powinien wiedzieć, umieć i jakie w ogóle jest spektrum tego, żeby się później w nim specjalizować jeszcze w jakichś zawężonych obszarach. I tam już 2 albo nawet 3 tygodnie z całych 21, czyli całkiem sporo, było poświęcone na DDD, tak w rozumieniu Evansa i trochę rozszerzone naszymi tamtejszymi rozkminami, że tak powiem. 

I popatrzyłem po latach, jakie pytania pojawiały się w tej tematyce na konferencjach, z czym ludzie przychodzą. Na naszym Slacku, gdzie było 8 tys. osób, coś takiego, masa ludzi po prostu. I wokół czego były pytania? No wokół właśnie rozwinięcia tego, czym to DDD jest, jakieś heurystyki, procedury itd. 

Jedną opcją było: Okej, odpowiadałem na te pytania, ale zobaczyłem, że tam jest tyle materiału, który trzeba jeszcze zrobić i ludzie o to prosili, że czekaliśmy też po prostu na nowy przykład taki biznesowy w naszej głowie, którym moglibyśmy się podzielić, który byłby złożony. Teraz chyba możemy nieskromnie powiedzieć, że ten przykład, który mamy techniczno-biznesowy, czyli zarówno od strony technicznej, jak i biznesowej, chyba jest najbardziej rozwinięty przykład takiego obszaru DDD, który jest publiczny. Tak mi się wydaje, pewnie nie widziałem wszystkich. Ale taki najbardziej złożony, naprawdę. Pokazywałem go wielu osobom, Sławek też go pokazywał, opowiadaliśmy wielu osobom o nich, o tych problemach, które tam są. 

To jest naprawdę złożony system, taki jak klasa systemów, z którymi się mierzymy na prawdziwych akcjach ratunkowych, czyli nie jest to zamówienie, produkt i tego typu przykład, tylko coś bardzo głębokiego. Może nie bardzo, ale dużo bardziej złożone niż te naiwne przykłady, które na prezentacjach muszą wybrzmiać, bo inaczej jakbyś pokazywał coś bardzo złożonego, to zajęłoby Ci 3 godziny na to, żeby sam problem wprowadzić, tak? A po 45 minutach masz koniec czasu. 

Więc głównie z tego powodu zobaczyliśmy, jaki jest tych wektor pytań, o co pytają ludzie, o czym chcą posłuchać. Czekaliśmy na nowy przykład też swój, taki biznesowy i na zebranie ostatnich tych procedur, o których Sławek powiedział. 

SS: I to jest podsumowanie pewnego etapu w życiu. 20 lat zajmowania się tematem, 15 lat szkolenia, kilkanaście tysięcy ludzi przeszło przez moje ręce, trenerów z firmy drugie trzy razy tyle, więc zebrała się cała masa doświadczeń, o co ludzie typowo pytają, z czym typowo mają problem dydaktyczny, jak podejść do różnego rodzaju odbiorcy, żeby wyjaśnić, pokazać. 

Pytałeś jeszcze, kto może skorzystać. My pokazujemy płaszczyznę współpracy pomiędzy zespołem developerskim, architektami, analitykami, product ownerami, product managerami i project managerami też, więc wydaje się, że idealnie byłoby, gdyby cały zespół cały zespół pracujący nad rozwiązaniem, pewne elementy tej wiedzy miał w sobie po to, żeby mogli współpracować razem. Na poziomie strategicznym, jeżeli wszyscy będą mieli mapę kontekstów w firmie, w projekcie, na ścianie czy gdzieś tam na Miro i każdą decyzję pomiędzy zespołami podejmujemy na mapie kontekstów wszyscy razem, to wtedy unikamy typowych błędów, tak zwanego przeciekania dziedzin, ale też ludzie z tzw. biznesu zaczynają widzieć potencjał do produktyzacji pewnych funkcji, bo widzą: Aha, mój system jest zbudowany z takich elementów, jako czarne skrzynki. Nie musisz wiedzieć, jak on działa w środku. 

I jeżeli mam pewne tzw. generyczne kawałki, to mógłbym je opakować  tam w prosty górę i sprzedać to. Mam nowy feature. Nie wiedziałem tego wcześniej, bo nikt mi tego tak nie pokazał. Jestem w stanie zobaczyć, jak zespoły na siebie czekają. Jestem w stanie zobaczyć: Ej, to może zmieńmy decyzję biznesową, bo zrobimy to pół roku szybciej. Jestem w stanie zobaczyć na mapie kontekstów wałki, ktoś robi wałki w firmie. Widzimy, że te decyzje są nieracjonalne nie dlatego, że programiści są niemądrzy, nie, po prostu ktoś z biznesu chciał zawłaszczać pewne dane. 

I na poziomie taktycznym to zespoły developerskie, architekci, czyli jak ułatwić sobie życie po to, żeby móc np. łatwo zmienić zdanie co do mojej decyzji, po to, żeby móc na koniec szybciej coś wydevelopować. Wydaje się czasem, że jak tutaj porobisz tam trzy klasy więcej niż normalnie, to będzie dłużej. Nie, nie. Jeżeli pisanie klas zajmuje Ci dużo czasu, to coś jest nie tak chyba z Twoim ogarnianiem IntelliJ-a. 

To, że coś podzielę na kilka kawałków inaczej niż do tej pory, to spowoduje, że będzie im na przykład łatwiej testować, szybciej będę mógł je wymieniać, będę mógł łatwiej zmienić zdanie, będę mógł łatwiej zmienić zdanie o tym, w którym module czy tam kontekście ograniczonym leży dane pojęcie. Będą łatwo je przekładać. Jest parę takich technik implementacyjnych, które wpływają na szybkość developmentu. Więc właściwie na każdym poziomie wytwarzania, ponieważ naszym celem było stworzenie takiej kompletnej skrzynki z narzędziami, żeby nie zostawić Was z czymś takim: Ej, dobra, fajnie, zrobiliśmy sobie model, ale teraz to w kodzie nie wiem, jak to będzie wyglądać. Więc możesz, Kuba, powiedzieć może o klasach problemów, że każdą klasę mamy właściwie zaimplementowaną zupełnie inaczej. 

JP: Najpierw dodam, że pokażemy też, kiedy na przykład nie dzielić wcale, że kiedy np. metoda, która ma 200 linii kodu, będzie okej i tak ma być. Mimo tego, że w książkach napisane jest, że ma być to 10 linijek kodu, czy tam 7, nie pamiętam, to też jest płynna liczba, to nie. Są klasy problemów, które my chcemy mieć w jednym miejscu, a w niektórych, tak jak powiedział Sławek, nie. 

Właśnie, z tymi klasami problemów. Co my zauważyliśmy? Że człowiek, który już jest zaznajomiony jakoś z pojęciami DDD, czyli Encja, value object, agregat, polityka, fabryka, repozytorium, read model, event itd. na pewnym poziomie dojrzałości, tym początkowym, zaczyna myśleć tymi wzorcami, ale nie do końca wie, gdzie jest aplikowalność tych wzorców. Czyli gdzie mam coś zastosować. Widziałem wielokrotnie później po poznaniu agregatu i tak sam tworzyłem rozwiązania, które szukały agregatu w miejscach, w których on nie był potrzebny w ogóle. I przepalamy czas. 

Więc jeżeli mój model mentalny, czyli moje poznawanie świata jest właśnie sterowane tym, jakie ja znam bloki, te bloki to są akurat z książki DDD, która jest świetna, to mogę wpaść w taką pułapkę. My chcemy wyjść trochę poziom wyżej, chyba jeden krok wyżej. Krokiem wyżej byłyby klasy problemów, które są agnostyczne od jakiejkolwiek metodyki wytwarzania programowania. Czyli np. tutaj mam problem z sytuacją, gdzie współbieżnie ludzie mi zmieniają wspólny stan i ja muszę upewnić się, że oni sobie nie weszli w drogę, a jak weszli sobie w drogę, to że nie popsuli mi jakichś reguł bardzo ważnych. Rywalizują o zasoby. 

Uczymy ludzi rozpoznawać, kiedy taki problem może występować, jak go zauważyć, jakie pytania analityczne sobie zadać, żeby w ogóle zauważyć, że to jest ta klasa problemu. Do tego akurat są agregaty. Ale to jest kolejny krok. Ja najpierw muszę zrozumieć, że tutaj mam taką rywalizację, żeby zrozumieć, z czego ten agregat wynika. 

Później są problemy typu transformacje slash obliczenia. To mogą być bardzo złożone transformacje jednego źródła danych albo kilku różnych w jakiś konkretny wynik. To może być wyliczenie, uwaga, polityki przykładowo z DDD, czy tam strategii z OOP. To są problemy z natury niestanowe. Zupełnie inaczej będę myślał i modelował w tym miejscu i właśnie tutaj jak jest procedura obliczeniowa, to ja wbrew pozorom często chcę mieć ją w jednej klasie właśnie po to, żeby nie skakać. W tym miejscu nie chcę skakać, bo zazwyczaj rozumiem ją w całości. Ewentualnie dostrajam ją politykami. 

Problemy integracyjne, czyli integruję różne systemy. Często jest pytanie: No my tu szukaliśmy tych agregatów, znaleźliśmy, ale to bez sensu wyszło. A jaką macie klasę problemu? No przerzucamy widłami XML-a do JSON-a. Okej, no nie ma tutaj szans na rywalizację o zasoby. Tutaj generalnie mamy problem właśnie złożonej transformaty i integracji. Bardziej będę myślał w kontekście gwarancji dostarczenia, jak to wysłać, komu wysłać, kiedy wysłać, być może wydajności. Takie problemy mnie interesują. 

Takim najprostszym przykładem problemu integracyjnego jest to, że ja muszę swój stan Twojej aplikacji zintegrować z bazą. Czyli muszę zapisać stan ulotny. To jest w jakiś sposób integracja. Integruję moją aplikację, ona ma pamięć w RAM-ie i teraz muszę to zrzucić do bazy danych i zrobić to dobrze. Jest to problem integracyjny. Do tego na przykład mamy w najprostszym przykładzie serwisy aplikacyjne. Ale jak już wiem, do czego są, to będę wiedział, kiedy je stosować, a kiedy mogę sobie darować na przykład tworzenie osobnej klasy na serwis aplikacyjny. 

Kolejne przykłady to jest specyficzny sposób transformacji danych, czyli prezentacja danych. Muszę zaprezentować jakąś informację i być może ona pochodzi z wielu źródeł i teraz są różne techniki, żeby zrobić to wydajnie. Read modele. Ale znowu, muszę zrozumieć, że ja tutaj tylko prezentuję dane i potrzebuję to zrobić prawdopodobnie w wydajny sposób. Być może mogę wziąć dane z cache’a, a nawet na pewno często mogę wziąć takie dane z cache’a. To jest zupełnie inna klasa problemu. 

I problemy, które my sobie nazywamy notatkami. Czyli zapisuję sobie dump mojego umysłu. Później go odczytuję, później go ewentualnie zmieniam, a później go kasuję. Czyli CRUD-y. Okej, mam klasy problemów. My cały tydzień poświęcamy na to, jak rozpoznawać klasy problemów bez używania tych słów w ogóle. Tylko jak rozpoznać klasę problemu, a potem kolejne 3–4 tygodnie mówimy, jak je rozwiązywać akurat za pomocą nazw, które w DDD istnieją, ponieważ nie jesteśmy aż tak zarozumiali, żeby tworzyć swoje nazwy na rzeczy, które już są dobrze nazwane. Ewentualnie dodajemy didaskalia, że być może ta nazwa nie jest zbyt fortunna i gdybyśmy mieli nazywać to od zera, to byśmy może użyli takiego słowa. Natomiast nie robimy tego, ponieważ to już istnieje w nomenklaturze i po to to zmieniasz. 

Ale jak już wiem, z czego to wynika, to wiem, gdzie jest stosowalność i uwaga, wiem, gdzie tej stosowalności nie ma. Wydaje mi się, że klasy zawodnika poznaje się po tym, kiedy wie, kiedy narzędzia jakiegoś nie stosować. Np. kiedy to będzie bez sensu. Przez to wstaw sobie dowolny wzorzec, który gdzieś tam np. w skrzynce z narzędziami pod tytułem DDD jest. 

 

Tak, bez dwóch zdań. Czyli innowacyjna forma, lata doświadczeń, dump umysłu Sławka i Kuby. Zapraszamy na domaindrivers.pl. A na dzisiaj myślę, że będziemy powoli kończyć. Sławek Sobótka, Jakub Pilimon, bardzo Wam dziękuję panowie za spotkanie. 

 

SS: Dzięki. 

JP: Dzięki.

Na koniec powiedzcie jeszcze, gdzie Was możemy znaleźć w internecie, albo gdzie możemy słuchaczy w tym temacie dalej odesłać. 

JP: Głównie właściwie w trybie write, czyli odpisywanie to głównie jest tylko LinkedIn. Czasem na Instagramie odpiszę. A nie, czekaj. Dobra, najpierw Sławek niech powie, później doprecyzuję. 

SS: Tak, ja głównie używam maila. Na LinkedIn też odpisuję i tyle. Staram się nie używać social mediów, za wyjątkiem tego, co Kuba chce powiedzieć. 

JP: Bo powiedziałeś, Krzysztof, o innowacyjnej formie szkolenia. Do tej pory to, co powiedzieliśmy, nie wiemy, czy jest innowacyjne. Może ideogram, sposób przekazu, ale co jest innowacyjne, to to, że w naszym szkoleniu, to jeszcze nie padło podczas tej rozmowy, tak z 5% materiału, to są scenki dydaktyczne, czyli są postacie, które pokazują pewnego rodzaju zachowania. Na tyle one zażarły, że postacie wyszły spoza tego miejsca, do którego zostały wykreowane, czyli do szkolenia i są już na socialach też. Sławek ma swoje alter ego w postaci Mariana Krudzińskiego i można znaleźć go na LinkedIn i na Instagramie. Na Instagramie Sławek tam jest, Marian Krudziński, a ja mam Briana Eryka II Drajwińskiego. Też na tych samych socialach można znaleźć i tam odpisujemy w 100%. 

 

Pięknie, pięknie. Oczywiście wszystkie te namiary będą w notatce do odcinka. Zapraszamy do śledzenia tych kont Waszych oryginalnych i Waszego alter ego. Bardzo Wam dziękuję za dzisiejsze spotkanie, za rozmowę. I oczywiście wszystkie te linki, łącznie z Domain Drivers, gdyby ktoś sobie nie potrafił tego wpisać, będą w notatce do odcinka. Zapraszamy do dołączenia do szkolenia, przedsprzedaż do 8 marca. 

Dzięki wielkie, Panowie. Cześć! 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Przypominam o najnowszym szkoleniu z DDD autorstwa Sławka Sobótki i Kuby Pilimona, a wydawanym przez organizatora takich hitów jak Droga Nowoczesnego Architekta czy Legacy Fighter, czyli Maćka Anicerowicza. To więcej niż kurs, to praktyczna nauka z niespotykanymi metodami dydaktycznymi, która pozwoli Ci zgłębić tajniki DDD na realnych przykładach. Nie przegap przedsprzedaży, która trwa do 8 marca. Już ponad 1000 osób zdecydowało się wziąć udział. Dołącz do nich i zarejestruj się na domaindrivers.pl.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Domain Driven Design. Zapraszam do kolejnego odcinka już wkrótce. 

Cześć!