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/
Notify of
trackback

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

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

Bogusz
Darek
Darek

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

Maciek
Maciek

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

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

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

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

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

reVis

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

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

Ś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

@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ę… Read more »

Rafał B

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

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

Piotr Nowak
Piotr Nowak

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

Mandro

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

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

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ć,… Read more »

Andrzej

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

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… Read more »

Artur R
Artur R

@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.… Read more »

asdf
asdf

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

Rafał B

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

Sławek

@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… Read more »

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… Read more »

asdf
asdf

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

@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

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

@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

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

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

asdf
asdf

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

asdf
asdf

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

Facebook

Książka

Zobacz również