DevTalk#14 – CQRS with Udi Dahan

20

udi-dahanPost po polsku poniżej / Polish version below


14th episode of DevTalk is a special one. First of all: this is the first episode in english! Second: my guest is a well-known, widely respected expert, the one and only Udi Dahan!

Udi is a creator of NServiceBus and founder of Particular Software. His thoughs about software architecture and best development practices – that often define the “industry standards” – can be found on a fascinating blog. Udi is one of the best-known speakers worldwide. He also offers advanced technical courses. Follow him on Twitter: @UdiDahan.

We talk about CQRS – Command Query Responsibility Segregation. Udi – together with Greg Young – was one of the first promoters and teachers of this approach to building complex software systems. BUT we do not discuss various CQRS implementation details. This conversation focuses on something that is often ignored by developers: what should we do to meet end users’ needs, not always putting our own desire to implement the “newest and shiniest” at the top of our priority list? And how can CQRS help us with that?


Odcinek 14 jest kolejnym odcinkiem wyjątkowym. Po pierwsze: bo to pierwszy odcinek po angielsku! A po drugie: bo mój gość to szanowany na całym świecie, znany wszem i wobec, niewymagający przedstawienia: the one and only Udi Dahan! Gdyby pół roku temu ktoś powiedział mi, że DevTalk wyjdzie poza granice Polski, i to od razu z Gościem tego kalibru, to bym się tylko w czoło popukał. A tu proszę…

Udi to twórca NServiceBusa – projektu, którego sukces spowodował założenie firmy Particular Software. Swoimi myślami odnośnie architektury oraz najlepszych praktyk programistycznych, definiującymi niejednokrotnie postrzeganie wielu zagadnień na całym świecie, dzieli się na fascynującym blogu. Jest jednym z najbardziej rozpoznawalnych prelegentów na największych światowych konferencjach. Prowadzi również szkolenia. Na Twitterze: @UdiDahan.

Tematem odcinka jest CQRS – Command Query Responsibility Segregation. Udi – wraz z Gregiem Youngiem – był jednym z pierwszych promotorów i nauczycieli tego podejścia do tworzenia oprogramowania. Nie wchodzimy jednak w szczegóły implementacyjne – w tym spotkaniu szkoda na to czasu! Ten temat pewnie jeszcze się pojawi w DevTalku w czysto technicznym kontekście, jednak z Udim rozmawiam z trochę ogólniejszej perspektywy. Udi tłumaczy dlaczego technologie i wzorce często nie są najważniejsze i na interesującym przykładzie pokazuje, jak wymagania biznesowe oraz modelowanie pomagają rozwiązać najtrudniejsze problemy. Programiści słysząc CQRS myślą od razu o klasach, szynach, cache itd, bardzo często pomijając kluczowy krok: refleksję nad źródłem i naturą rozwiązywanego problemu. Słuchając tego odcinka każdy dev zastanowi się pewnie: czy przypadkiem ja nie ignoruję faktycznych potrzeb użytkowników?

Bardzo zachęcam do posłuchania, bo taka okazja nie zdarza się co dzień.

Ten odcinek ma partnera specjalnego: firmę JIT Solutions z Gdyni. Gdybyście chcieli sprawdzić w praktyce jak m.in. NServiceBus jest wykorzystywany w dużym rozproszonym projekcie to macie okazję dołączyć do ich zespołu. Szczegóły znajdziecie na pracuj.pl lub bezpośrednio w tym PDF.

JIT_solutions

Konkurs: po raz drugi (wcześniej w odcinku o DDD) do rozdania mam “Implementing Domain-Driven Design” Vaughna Vernona. Poza anteną wprost spytałem Udiego jaką jedną książkę poleciłby programistom, a on wskazał na tę konkretną pozycję. Właśnie ją zatem wyślę do autora jednego z komentarzy pod tym postem. Jak zwykle apeluję: piszcie swoje uwagi! Zarówno do odcinka, jak i samej idei “importowania” gości z zagranicy :). Mi się pomysł podoba – i ciekawą znajomość można nawiązać, i po angielsku pogadać, i nowych słuchaczy przyciągnąć. Co Wy na to?



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

Linki:


Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

20 Comments

  1. Pingback: dotnetomaniak.pl

  2. Jacek Malaca on

    Pomysł na odcinek i na gościa świetny :) Temat pasuje zresztą do ostatnich dyskusji na temat CQRS jakie miałem ze znajomymi, teraz pewnie wrócimy do rozmowy.

  3. Grzegorz Kotfis on

    Czuje, że idea wspólnego spotkania wyszła już po konferencji get.net w Gdańsku ;)

  4. Jacek,
    Cool, temat na czasie, to prawda :).

    Grzegorz,
    Masz rację – pierwszy plan pojawił się na speakers dinner w dniu konferencji. Mam teraz kolejny argument za jeżdżeniem na konferencje :).

  5. Temat w dechę. Akurat jestem na etapie projektowania zestawu serwisów, za pomocą którego nasz system będzie mógł wymieniać dane z systemami ERP (na razie SAP i MS Dynamics) oraz udostępniać część logiki biznesowej na zewnątrz – dla innych serwisów lub klientów i niektóre elementy tego rozwiązania zamierzam zrealizować właśnie w oparciu o CQRS i być może mikro serwisy :)

  6. W ogólę fajny pomysł z tymi devtalkami:) szukałem czegoś takiego kiedyś, ostatnio chciałem się zagłębić w CQRS więc wierzę, że to będzie dobry czas:)

  7. Dzisiejszy odcinek DevTalk wygrał rywalizację z DotNetRocks. A skoro już jesteśmy w temacie DotNetRocks, to może by tak, któryś z przyszłych odcinków spróbować zrobić z Carlem Franklinem? To by było coś.

  8. mi--ch--al on

    Szacunek wielki z ten odcinek!
    Czyli…można używać wszystkich TDDDDDBDD i innych xDD a i tak na produkcji jeden niepozorny transakcyjny select+update może “wywrócić” system ;)))
    ale przecież “u mnie działa” -> 1 user -> none collaborative domain
    i na testach też działało -> 5 user’ów -> small collaborative domain
    więc dlaczego na produkcji nie działa ? -> 10…00 user’ów -> very high collaborative domain
    ;)))

  9. Wow :) od razu przełączyłem się na odsłuch jak tylko zdałem sobie sprawę, że jest po angielsku. Trafiony – zaimplementowany :)

  10. Świetny odcinek! Miło posłuchać przemyśleń na temat nieco bardziej zaawansowanych problemów. Myślę, że problem high-contention spowodował osiwienie niejednej programistycznej głowy z powodu braku sprawdzonych recept, więc ukłony dla devtalk za szerzenie wiedzy w tego rodzaju tematach. Takiego contentu brakuje, takiego contentu nam trzeba. Przyjemność słuchania. Dzięki :)

    Łyżka dziegciu w beczce miodu: myślę że ktoś nowy w temacie CQRS może poczuć się zagubiony po odsłuchaniu tego odcinka. Brak omawiania szczegółów implementacyjnych – OK, ale brak nieco dłuższego rozwinięcia pojęcia CQRS może takiego zieleńszego słuchacza zostawić z połaciami wątpliwości. A jeśli chodzi o kwestie organizacyjne to mam wątpliwości co do początkowej wstawki po polsku. Ktoś zagraniczny może doznać audiofonicznego szoku słuchając naszej twardej słowiańskiej mowy ;)

  11. Bardzo dobry odcinek. Devtalk rozwija się świetnie, myślę że czas powoli zastanowić się nad współprowadzącym :).

  12. Hav,
    Łał jakie słowa, dzięki :).
    Co do Carla Franklina – akurat jego na swojej liście “do nagrania zza granic” :) nie mam. Taki odcinek wymaga o wiele więcej przygotowań niż odcinki “normalne” (które zresztą też trochę zajmują) i będą się pojawiać raczej sporadycznie. Gdy tylko wpadł mi do głowy pomysł rozmów zagranicznych to Udi od razu pojawił się na pierwszym miejscu, a co będzie dalej – zobaczymy.

  13. Paweł,
    Dzięki!
    Masz rację, nie ma tutaj nic o CQRS w sensie ogólnym ani implementacyjnym. To zabieg celowy. Wiedziałem mniej więcej co chcę od Udiego usłyszeć i tak starałem się kierować rozmową, aby mieć nagranie dokładnie jego podlądów – bo nikt inny w ten sposób o CQRS nie mówi. “Świeżak” w temacie CQRS ma pod postem linki do poczytania. A w przyszłości pojawi się też pewnie bardziej techniczny odcinek o CQRS.
    Co do wstawki po polsku – bez przesady, to raptem kilka słów :).

  14. Jarek,
    Thx za sugestię, kwestię współprowadzącego kiedyś rozważałem i odrzuciłem taką koncepcję, ale może kiedyś do niej wrócę – ale raczej nieprędko bo to generowałoby spore zamieszanie a nie do końca widzę z tego korzyści. Na razie jest jak jest :).

  15. Łukasz,
    Dzięki za linka, nie widziałem tego (a szukałem “udi cqrs podcast” po guglach jak dziki :) i dotnetrocks przesluchałem wcześniej kilka razy robiąc notatki, żeby nie duplikować treści).
    Podzielam Twój pogląd na temat gości zagranicznych – dlatego to będą wyskoki raz na jakiś czas. Ale cieszę się że się podobało :).

  16. Odcinek jak najbardziej na czasie, właśnie zacząłem rozpoznanie tematu od książki CQRS Journey* .
    Jak to zwykle bywa, na początku wiele tematów nie jest wcale tak oczywista.
    Za to każda kolejna porcja wiedzy przybliża do zrozumienia zagadnienia.
    Ostatnio ciężko myślałem nad tym, gdzie, jak i kiedy zastosować to podejście.
    No i proszę, usłyszałem całkiem sensowną podpowiedź:
    Niekoniecznie cała aplikacja musi wzorzec CQRS wykorzystywać,
    można z powodzeniem to podejście zastosować tylko do części funkcjonalności.
    … i tak, wiem, że to oczywiste, ale dopiero wtedy kiedy się o tym wie ;-)

    I jeszcze nawiążę do Twojego pytania o wciągnięcie “business peoples”, do podejmowania decyzji o architekturze.
    Możliwe, że miałem wyjątkowego pecha, albo pracowałem dla kompletnie innych firm.
    Sporadycznie trafiam na osoby które dokładnie wiedzą czego potrzebują i wtedy praca jest dużo prostsza i przyjemniejsza.
    Dużo częściej “business peoples”, mają dosyć ograniczone pojęcie, o tym jak ich firma funkcjonuje.
    I to im większa firma tym pojęcie jest mniejsze.
    “Wrzucam to w komputer i komputer daje mi wynik”
    “Jak mi się wyświetli na czerwono, to wysyłam do Anki”
    “Dwa razy tab, F3, ENTER, zaznaczam najwyższy checkBox, ENTER, Ctrl+END”( to w odpowiedzi na pytanie o kryteria zatwierdzania dokumentów)
    To tylko kilka cytatów, a słyszałem podobnych bardzo dużo.
    Dominuje, niestety, przyzwyczajenie do funkcjonalności jakiejś prastarej aplikacji, która w danej firmie zagościła jako pierwsza.
    Bardzo często nie jest najlepiej napisana i wymusza bardzo nieefektywne podejście do pracy,
    które z czasem przeradza się w formalne procedury. Konsultacje z ludźmi biznesu, w tym wypadku, niewiele pomagają.
    Nie ma w takiej sytuacji innego sposobu jak tylko samodzielne rozpoznanie tematu i zaproponowanie rozwiązania.
    Myślę, że wpisuje się to w odwieczny problem. Na ile pozwolić klientowi samemu zdecydować a na ile “ratować” go na siłę.

    Bardzo brakowało takiego podcastu w języku polskim i szkoda by było go stracić.
    Język angielski, jeśli można poprosić, tylko okazyjnie.

    * CQRS Journey

  17. Super odcinek, jeden z kilku, które skłoniły mnie do zainteresowania się zagadnieniem :)

  18. Super odcinek, świetny gość i temat. Bardzo podobało mi się to co powiedział Udi, aby CQRS traktować jako podejście, a nie tylko jako wzorzec! Myślę, że bardzo dobrze, że poszliście w rozmowie w tą stronę, zamiast omawiania CQRS jako wzorca. O tym można sobie przeczytać w mądrej literaturze albo internetach. ;) Domena, która pojawiała się w przykładach jest mi bliska i mam dzięki trochę świeższe spojrzenie na projekt, przy którym pracuję. Dzięki!

Newsletter devstyle!
Dołącz do 2000 programistów!
  Zero spamu. Tylko ciekawe treści.
Dzięki za zaufanie!
Do przeczytania wkrótce!
Niech DEV będzie z Tobą!