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:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki do materiałów z nagrania:
- filmik o siedmiu prostopadłych liniach:) (https://www.youtube.com/watch?v=BKorP55Aqvg)
- blog Sławka (http://art-of-software.blogspot.com)
- materiały o DDD z Bottega (http://bottega.com.pl/artykuly-i-prezentacje#ddd)
- referencyjny projekt Bottega (http://bottega.com.pl/ddd-cqrs-sample-project)
- książka Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software” (http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)
- książka Vaughna Vernona “Implementing Domain-Driven Design” (https://vaughnvernon.co/?page_id=168)
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/
04 – O Domain Driven Design z S. Sobótką | DevTalk
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Updated: DevTalk – Programistyczny głos w Twoim domu
http://groopmark.com/link/details/181/devtalk-programistyczny-glos-w-twoim-domu?cid=11
Bardzo ciekawy wywiad szkoda, że taki krótki.
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.
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.
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 ;)
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
Z dźwiękiem jest ok, Ciekawy wywiad – szkoda, że taki krótki :)
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
Revis,
Rozmiar mp3 to zawsze 30-40 MB.
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 …”.
Ś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 :)
@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ę…
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.
Bardzo ciekawa rozmowa. Z każdym kolejnym odcinkiem coraz lepiej oby tak dalej :)
Programista to stan umysłu nie konkretna technologia czy framework lub język dlatego tak bardzo przemawia do mnie idea ddd
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?
MANDRO,
DDD z Sharepoint – ja nawet nie wiem jak się ustosunkować:). W sumie można traktować SP jako tylko “źródło danych” i nad niego nadpisać jakąś warstwę “dostępu”. A wyżej programować jak Evans i Vaughn nakazują, ale… nie wiem czy to w ogóle droga dokądkolwiek. Tak jak napisałeś, workflowy, eventy itd są w SP obecne i trzeba się “jakoś” z tym wszystkim spiąć, co niestety wymaga kupy kupy. Ja osobiście średnio widzę taką możliwość – ale nie tylko ze względu na fakt, że SP powinien gnić w piekle a nie na maszynach developerskich, a też z uwagi na naturę systemów pisanych na tą platformę.
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.
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.
BOMBEL,
Właściwie każdy temat poruszany do tej pory pozostawia niedosyt i zasługuje na kontynuację, może po prostu za jakiś czas nagram odcinek drugi każdego dotychczasowego :) . Ale tak serio: staram się trzymać (własnej) zasady “max 40 minut”. O wszystkim można gadać i gadać, ale zbytnie rozwlekanie mogłoby być nudne… no i aktualna długość gwarantuje optymalny czas poświęcany przez każdego na dany odcinek.
A co do kontynuacji w postaci odpowiedzi na pytania: super pomysł, który… mam na liście “todo” od samego początku:). Zobaczymy, może kiedyś zostanie to wdrożone, na razie jeszcze cały czas staram się wplatać DevTalk w swoją codzienność, wypracować jakąś rutynę. Póki co namawiam Gości do udzielania się w dyskusji w komentarzach pod postem.
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
ANDRZEJ,
Rozwaliło mnie, thx :)
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.
@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.
Co zrobić, gdy z metody biznesowej (encji) trzeba wysłać mejla, a do encji nie można nic wstrzykiwać? :C
Jednym z prostszych rozwiązań na to są Domain Events: http://www.udidahan.com/2009/06/14/domain-events-salvation/
@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.
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.
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 :)
@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…
@ASDF
Agregaty powstają w pamięci dzięki fabrykom i w repozytoriom.
Tam możesz dokonać wstrzyknięcia. Uczyń z fabryk i repo komponenty zarządzane, wstrzyknij do nich przez CDI co chcesz, a później przekaż referencje do encji.
Tak to robiliśmy w LeavenV1:
https://code.google.com/p/ddd-cqrs-sample/source/browse/trunk/ddd_cqrs-sample/src/main/java/pl/com/bottega/erp/sales/infrastructure/repositories/jpa/JpaOrderRepository.java
https://code.google.com/p/ddd-cqrs-sample/source/browse/trunk/ddd_cqrs-sample/src/main/java/pl/com/bottega/erp/sales/domain/OrderFactory.java
A tak w V2 – spring.autowireBean() – jak widać Spring jest światłością i świetnością;)
https://github.com/BottegaIT/ddd-leaven-v2/blob/master/src/main/java/pl/com/bottega/ecommerce/sales/domain/reservation/ReservationFactory.java
Ew. jak wpomniałem można rzeczy aplikacyjne zrobić w serwisie apliakcyjny/command handlerze:
https://github.com/BottegaIT/ddd-leaven-v2/blob/master/src/main/java/pl/com/bottega/ecommerce/sales/application/impl/OrderingServiceImpl.java
https://github.com/BottegaIT/ddd-leaven-v2/blob/master/src/main/java/pl/com/bottega/ecommerce/sales/application/api/handler/AddProdctCommandHandler.java
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
@Sławek: dziękuję!
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.
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.
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 :)
Strasznie ciekawy podcast. Procent jestem bardzo wdzięczny za ten cykl :)
” No, you don’t have DDD when your entities have methods.” :D
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