fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
2 minut

DevTalk#04 – O Domain Driven Design ze Sławomirem Sobótką


01.12.2014

slawek-sobotka

Czwarty odcinek to badanie nowych gruntów: wyjście poza .NET! Moim gościem jest Sławomir Sobótka: założyciel firmy Bottega IT Solutions, trener, blogger, architekt. Wywodzi się ze środowiska Javy i można go spotkać na bardzo wielu konferencjach i grupach związanych z tą właśnie technologią.

Rozprawiamy o Domain Driven Design, a Sławek jest jednym z najbardziej rozpoznawalnych polskich ekspertów w tym obszarze. Podczas rozmowy opowiada nam jakie korzyści niesie za sobą DDD, “jak zacząć”, czego się wystrzegać i skąd czerpać wiedzę. Powinno być ciekawie zarówno dla całkowitych świeżaków jak i osób bardziej siedzących “w temacie”.

Konkurs: Sławek sponsoruje książkę Vaughna Vernona “Implementing Domain-Driven Design”. Otrzyma ją – podobnie jak w poprzednim odcinku – autor jednego z komentarzy, które pojawią się pod tym postem. Ale – uwaga! – to Sławek wybierze zwycięzcę. Zadawajcie więc pytania, udzielajcie się, drążcie temat, a nasz ekspert będzie czynnie uczestniczył w dyskusji.


Montaż odcinka: Krzysztof Śmigiel.
Ważne adresy:

Linki do materiałów z nagrania:

Bottega

P.S. Jeszcze jedno: ostatnio w komentarzach sporo pisaliście o tym jak to nienaturalnie brzmię na nagraniu “poza rozmową”. Mam nadzieję że tym razem jest trochę lepiej, dajcie znać czy faktycznie:).


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
0 0 votes
Article Rating
40 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback
9 years ago

04 – O Domain Driven Design z S. Sobótką | DevTalk

Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl

Bogusz
9 years ago

Updated: DevTalk – Programistyczny głos w Twoim domu
http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11

Darek
Darek
9 years ago

Bardzo ciekawy wywiad szkoda, że taki krótki.

Maciek
Maciek
9 years ago

Jak na pół godzinną rozmowę całkiem treściwa :) Aż mi się przypomniały czasy, gdy sam pozwałem DDD.dsds

PS. Czy ten Włoch to nie był przypadkiem Alberto Brandollini? Brzmiało trochę jak Event Storming, który ostatnio promuje.

Sławek
9 years ago

Tak, Brandollini. Eventsorming był wówczas w fazie eksperymentalnej, natomiast karteczki, o których mówiłem to jeszcze inna technika- grupowanie zachowań wg niezmienników.

Rafał B
9 years ago

Bardzo ciekawa rozmowa, o DDD nigdy za wiele! ;) Jedno przemyślenie: zgadzam się, że do CRUD nie ma co stosować DDD, ale z moich obserwacji wynika, że aplikacji CRUD-owych jest stanowczo za dużo, zwłaszcza w korporacjach. Często wynika to z braku głębszej wiedzy o procesie biznesowym wśród programistów czy analityków. W efekcie masowo powstają nakładki na bazę danych, a nieświadomi użytkownicy realizują swój faktyczny proces “ręcznie”, np. workflow przez maila, eksport danych do Excela do właściwego przetwarzania itd. Także unikanie fanatycznego stosowania DDD nie powinno w żadnym razie implikować spowalniania antyCRUDowej krucjaty ;)

Maciej Hadam
Maciej Hadam
9 years ago

Cześć,

W wywiadzie użyte było porównanie modelu domenowego do praw fizyki zachodzących na stole bilardowym.
Czy w tym porównaniu jest również miejsce na osobny model widoku jaki występuje w architekturze opartej na wzorcu CQRS?
Mamy go w głowie i uaktualniamy go widząc i słysząc?
Pozdrawiam

Paweł Srebniak
9 years ago

Z dźwiękiem jest ok, Ciekawy wywiad – szkoda, że taki krótki :)

reVis
reVis
9 years ago

Kolejna sugestia. Czy razem z linkiem do mp3 można zamieścić też od razu rozmiar pliku? Od strony urządzeń mobilnych i streamu przez sieć komórkowa może być to kluczową informacja. Pozdrawiam

Grzegorz Kotfis
Grzegorz Kotfis
9 years ago

Bardzo ciekawa rozmowa, w której przez chwilę pojawił się temat „kultury pracy” w zespole programistycznym. Dla mnie jest to istotna sprawa. Jedną z bardziej irytujących rzeczy jest właśnie takie wspomniane wytykanie błędów oraz uosabianie kodu, czyli gadki typu „bo ty robisz tam w aplikacji to i to …”.

Artur R
Artur R
9 years ago

Świetny materiał. Moment przejścia z DDD na neurobiologię mnie powalił :)
Mi pozostaje tylko czekać na udane wdrożenie DDD w aplikacjach SharePointowych. Kiedyś nawet myślałem, że ta sztuka udała się w jednym z projektów w których brałem udział ale to było niestety tylko złudzenie.
Pozdrawiam i czekam na więcej materiałów z zakresu DDD :)

Sławek
9 years ago

@Maciej: gdybym miał pociągnąć dalej paralelę fizyki w kierunku cqrs, to powiedziałbym, że read model jest raportem z rozgrywki, np: ilość odbić, ilość uderzeń, ilość kolorów danych bil w uzach itd…

@Rafał: to Twoja prezentacja na LDI natchnęła mnie do DDD:) Co do CRUDów, to faktycznie – często jest w nich jeszcze jedna warstwa: głowa usera:P
Ale to generalny problem: UI nastawione na możliwości jest lepsze dla eksperta, UI nastawiona na zadania będzie lepsze dla początkujących…

Co do CRUDów jeszcze, to czasem jest tak, że biznes nauczył się mówić czasownikami crud, bo zauważyli, że z “cyborgami z it” tak się rozmawia. Czyli to jest nasza wina (lub naszych “przodków” z czasów delphi;), że narzuciliśmy taką retorykę…

Rafał B
9 years ago

Dzięki ;) Ja z kolei na DDD trafiłem po długotrwałym kombinowaniu na potrzeby projektu – przeszukiwałem ebooki w necie i odkryłem… nie, nie Evansa (to dopiero w kolejnym kroku), ale książkę Jimmy’ego Nilssona “Applying Domain-Driven Design and Patterns” – mocno praktyczną, przepełnioną listingami w C#, dzisiaj już raczej zapomnianą. I tak myślę, że to się zgrywa z tym co powiedziałeś w audycji – gdybym nie zapalił się do tematu od strony programistycznej dzięki takiej praktycznej książce, to możliwe, że Blue Book nawet nie tknąłbym kijem.

Łukasz
Łukasz
9 years ago

Bardzo ciekawa rozmowa. Z każdym kolejnym odcinkiem coraz lepiej oby tak dalej :)

Piotr Nowak
Piotr Nowak
9 years ago

Programista to stan umysłu nie konkretna technologia czy framework lub język dlatego tak bardzo przemawia do mnie idea ddd

Mandro
9 years ago

Fajna rozmowa, idealnie sie słucha stojąc w korkach ;-)

A czy macie jakieś doświadczenie w łączeniu DDD z Sharepoint’em? Zauważyłem że szerpojntowcy uwielbiają zatruwać kod szczegółami implementacyjnymi. A może komuś udało się sprawnie połaczyć to z tymi wszystkimi workflowami, event receiverami itd?

bartek
bartek
9 years ago

Fajny wywiad. Ja na DDD trafilem przez nauke o wzorcach projektowych. Potrzebowalem czegos ogolniejszego jako pomoc przy modelowaniu i tak trafilem na blog Slawka Sobotki. Potem juz byla blue book i red book i jakos poszlo.

Bombel
Bombel
9 years ago

Fajna rozmowa. Dużo się teraz mówi o DDD, wszyscy na siłę próbują go wciskać gdzie popadnie, więc fajnie, że w rozmowie pojawiły się wskazówki, gdzie nie należy go stosować. Czasami wiedza, gdzie coś nie działa jest bardzo przydatna i pozwala uniknąć wielu rozczarowań. Metafory również bardzo na plus. Szkoda, że taka krótka ta rozmowa, miło się tego słuchało i liczę na kontynuację.
Maćku, w komentarzach na tej stronie pojawiają się pytania merytoryczne do tematów poruszonych w nagraniach, może by w niedługim czasie po każdej rozmowie nagrywać kontynuację, w której Twój rozmówca mógłby odpowiedzieć na nie? Dzięki temu słuchacze mogliby poczuć, że nie tylko są biernymi odbiorcami, ale też mogą przyłączyć się do dyskusji.

Andrzej
9 years ago

To mówicie, że nie da się tych 7 prostopadłych linii? A może jednak dobry modelarz dałby radę? https://www.youtube.com/watch?v=B7MIJP90biM

Sławek
9 years ago

Odnośnie Sharepointa: na wstępie zaznaczam, że nigdy z tym nie pracowałem i znam jedynie ze smutnych opowieści z drugiej ręki.

Ale może dzięki temu mam dystans (oby nie wyszły z tego urojenia kosmonauty):
z tego co rozumiem, SP narzuca jakieś building blocks. Wydaje się, że raczej z domeny mocno technicznej. Problem pojawia się przy translacji tych BB na BB z DDD.

A gdyby tak próbować modelować BB z SP – zmieniając ich nazwę tak aby była mniej egzotyczna dla biznesu. Ew dodać kolejne BB, ew nadbudować nad tymi technicnzymi własne BB – niekoniecznie z DDD.

Być może te BB nie będą naturalne, ale da to też wyobrażenie tym co można w SP zrobić tanio (bo po to był kupiony;) a co wiąże się z syndromem “nakładania gaci przez głowę”. Wówczas będzie to raczej SP Diven niż Domain Driven, ale ktoś kupił tego SP aby właśnie w nim “wyklikać” coś, więc może o to chodzi aby zacząć myśleć o biznesie przy pomocy “foremek” z SP…

Nie wiem czy to ma sens.

Artur R
Artur R
9 years ago

@Slawek, @Mandro
Owszem, programowanie w SharePoincie to konieczność składania ze sobą gotowych kompotentów i poruszanie się w jakiejś z góry narzuconej piaskownicy. Efekt jest taki, że aplikacje SharePointowe są w rzeczywistości małe. Mówię tu o rozmiarze modelowanego problemu, a nie aplikacji w ścisłym znaczeniu.
Oczywiście trafiają się duże perełki. Sam miałem przyjemność uczestniczyć w bardzo dużym projekcie (nawet jak na SharePointa) gdzie DDD, by pasowało jak ulał. Niestety zabrakło doświadczenia i wyszedł z tego Anemic DM nad którym Martin Fowler mocno rozpaczał na swoim blogu. Potem ten Anemic DM kopał nas bezlitośnie gdy wraz z kolejnym sprintem wymagania biznesowe rosły.
No i teraz przejście do tego o czym wspominał Mandro. Aplikacje są małe (to moja opinia ale stawiam, że byłbym w stanie jej bronić), więc programiści od razu przechodzą na język techniczny. “Tu pierdykniemy receiver, tu jakiś Content Type i gotowe”. No i potem dostajemy taki zatruty kod.

asdf
asdf
9 years ago

Co zrobić, gdy z metody biznesowej (encji) trzeba wysłać mejla, a do encji nie można nic wstrzykiwać? :C

Rafał B
9 years ago

Jednym z prostszych rozwiązań na to są Domain Events: http://www.udidahan.com/2009/06/14/domain-events-salvation/

Sławek
9 years ago

@ASDF w DDD kluczowe jest odróżnienie logiki aplikacyjnej od domenowej – stąd 2 warstwy logiki. Można zadać pytanie: czy to, że trzeba wysłać maila to logika biznesu czy aplikacji? Zwykle aplikacji, więc takie problemy można zaadresować w tej warstwie. Chyba, że domena faktycznie jest zorientowana wokół maili…
Ew. jest to osobny bounded context.
Najczyściej byłoby jak pisze Rafał: event. Tutaj kluczowe jest utrzymanie Inversion of Control (zdarzenia – obok DI i Aspektów są techniką IoC), czyli event oznajmia fakt a nie jest rozkazem. Zatem event nie powinien mieć w sobie treści maila ani adresu maila, bo w sumie nadawca zdarzenia nie wie w jakim celu będzie ono nasłuchiwane.

Piotr Lazy<Developer> Perak

W 2009 przeczytałem niebieską książkę. Akurat chwilę później “napatoczył się” nowy projekt, który mogłem pisać od pierwszej linijki i natychmiast zastosowałem DDD – zgodnie ze słowami “Dla chłopca z młotkiem wszystko jest gwoździem”. I był to błąd. W aplikacji nie było wcale aż tak dużo logiki. Zmarnowałem na naukę kupę czasu (ok 3 miesiące projektu) – nawet swego czasu pomagał mi Vaughn Vernon na liście mailingowej domaindrivendesign – podczas gdy prawdopodobnie napisałbym tę aplikację w połowie tego czasu bez DDD. Książka Evansa jest dosyć abstrakcyjna i ciężko na jej podstawie usiąść i zacząć pisać. Przynajmniej tak mi się wydaje teraz po latach. Ale może, jak mówił Maciej, teraz wyniósłbym z niej coś innego/więcej. Tylko to taka kobyła, a w kolejce tyle książek. Prawdopodobnie do tej kolejki trafi teraz ta czerwona. A “Implementing” w tytule chyba podbije jej priorytet :)

Ale po samym odcinku mam pewien niedosyt. Nie do końca potrafiłbym komuś wytłumaczyć co to jest DDD. Albo inaczej. W poprzedniej firmie tworzyłem oprogramowanie dla jednego z ubezpieczycieli. Przez wiele lat brałem udział w tworzeniu oprogramowania zarówno dla agentów (sprzedaż) oraz dla pracowników w centrali (obsługa szkód). Logiki było tam bardzo dużo. I tak się zastanawiam, czy robiłem DDD? Kod nie powstawał bez analiz biznesowych. Z klientem mogliśmy zawsze porozmawiać. Wszystkie obiekty biznesowe miały swoje odzwierciedlenie w świecie rzeczywistym (szkody, zwyżki/zniżki, ryzyka, polisy, ubezpieczeni, likwidatorzy itd.). Procesy biznesowe były bardzo rozbudowane i zbudowane na jednej z platform do BPM.

Czy da się stwierdzić jednoznacznie, czy ktoś robi DDD? Że nie robi to łatwo :) Mam wrażenie, że w dzisiejszych czasach DDD jest bardzo modne i wielu osobom wydaje się, że robi DDD, chociaż tak naprawdę wcale tak nie jest.

asdf
asdf
9 years ago

Mój problem jest natury technicznej. Używam CDI, EJB, JPA. Encje JPA to zwykłe, niezarządzane przez kontener POJO- czyli nie mogę w nich używać wstrzykiwania (zależności czy zasobów). Nie dostanę się więc z metody biznesowej encji do sesji mejlowej, JMS, nie wyślę też zdarzenia CDI Event. No chyba żeby użyć JNDI Lookup, ale to już w JEE jest niemodne :)

Sławek
9 years ago

@Piotr – tak samo jak z Agile, BDD, SOA itd… każdy to “robi”:)
Moim zdaniem nie jest tak ważne czy ktoś postępuje nazwijmy to kanonicznie. Ważne, że zauważa problemy pewnej klasy i próbuje je jakoś adresować. Z czasem znajdzie swój sposób…

Sławek
9 years ago

Właśnie ukazała się moja prezentacja z Confitury, gdzie możecie zobaczyć część mojego podejścia do DDD http://art-of-software.blogspot.com/2014/12/nie-koduj-pisz-proze-techniki.html

asdf
asdf
9 years ago

@Sławek: dziękuję!

Piotr Lazy<Developer> Perak

Coraz bardziej skłaniam się ku stwierdzeniu, że korzystałem z DDD. Jak się zastanowić teraz to miałem nawet Anti corruption layers (integracja z różnymi systemami).
Temat zdecydowanie znowu mnie zainteresował, trzeba zobaczyć co się działo przez ostatnie lata w DDD.

Sławek
9 years ago

Zastanawiałem się kto by najbardziej skorzystał z książki, którą mam jako prezent dla słuchaczy i pomyślałem sobie, że skoro Piotr Lazyperak zadeklarował się, że chce przeczytać IDDD to pewnie mu się przyda wersja papierowa:)
Tak więc ogłaszam zwycięzcę: Piotra. Maciej skontaktuje nas aby ustalić szczegóły przekazania nagrody.

Piotr Lazy<Developer> Perak

O! Super!

Chciałbym tylko sprostować swoją ksywką. To nie Lazyperak, ale Piotr Lazy<Developer> Perak. Czasem trudno wprowadzić te nawiasy trójkątne w Webie :)

siararadek
siararadek
9 years ago

Strasznie ciekawy podcast. Procent jestem bardzo wdzięczny za ten cykl :)

asdf
asdf
9 years ago

” No, you don’t have DDD when your entities have methods.” :D

asdf
asdf
9 years ago

A jeszcze na chwilę wrócę, może komuś się przyda- odnośnie mojego pytania, w JEE7 można wstrzykiwać do @EntityListener. Metoda zwrotna dostaje encję w argumencie i tam można do niej przypisać wstrzyknięty obiekt. https://blogs.oracle.com/theaquarium/entry/better_cdi_alignment_in_jpa

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Książka

Zobacz również