TL; DR
Normalnie dałbym tutaj link do przygotowanej mapy… I tak też zrobię. Jednak warto przeczytać całość, zamiast obejrzeć nowy filmik HRejterów :)
MIRO BOARD LINK - Developer Journey Map - DDD & Event Sourcing
Z życia na kodach
Kiedy przerzucał kolejne karty tej niebieskiej świętej księgi, nagle poczuł, jakby znalazł się w innej, wspaniałej krainie. Mityczne miasto ze złota, kryształy Kyber, Skarb Narodów, święty Graal — to wszystko stało tutaj na wyciągnięcie ręki. Ehkm… obudził się, wisząc głową zaraz nad Backspace — ale sen jakby trwał nadal. Oczywiście… w sensie programistycznym — sen na Javie (i nie tylko). Czysty kod, odpowiadającym problemom biznesowym — to było to. Wszystko czytelnie przetestowane, ale nie zabetonowane, w sposób umożliwiający sprawny refaktoring modelu domenowego.
Nagle! To było to — pojął, iż dzielenie kodu na Controller / Service / Repository i nieszczęsne, anemiczne Domain (z samymi getterami i setterami) nie zawsze jest dobrą drogą. Zobaczył, iż to nie język programowania jest najważniejszy, ale Ubiquitous Language. Dotarło do niego, iż projekt nie musi stawać się jak legacy Big Ball of Mud — kompletnie nie do utrzymania już po 3 miesiącach (zobaczcie jak niemal każdy taki projekt, się zaczyna TUTAJ). Kod można dzielić na niezależne moduły i są na to zasady. Szuka się reguł biznesowych i tak wyznacza obiekty zwane agregatami, a nie “bo tak mi pasowało po nazwie klasy”. Zobaczył, iż ważne jest to, co się wydarzyło i zachowania, a nie aktualny stan i tabelki w bazie danych.
Linijki kodu przestały przypominać plątający się ze sobą makaron Spaghetti, który mama spakowała mu na drogę do słoika, wraz z parą zapasowych… można się domyślić czego :) Podjął decyzję, iż wyruszy w tą drogę, która zwie się Domain-Driven Design, chociaż nie do końca rozumiał, z czym to się je (sos bolognese to chyba nie to). Wyruszy jeszcze dzisiaj, a przebytą drogę też zaznaczył na mapie, żeby inni mogli ruszyć razem z nim. Zainteresowani? Macie mapę? No to w drogę!
DDD, czyli…
Domain-Driven Design. Z pewnością o tym słyszałeś. A Event Sourcing? Może się obiło o uszy… Niezależnie od tego, jaka jest Twoja odpowiedź, to dobrze trafiłeś! Są to umiejętności, które powinien poznać każdy świadomy developer. To zestaw sprawdzonych reguł do zostania Seniorem z prawdziwego zdarzenia. Nie tylko wpłynie to na zasobność Twojego warsztatu programistycznego, ale zmieni też Twoje myślenie, już na zawsze. Takim, który potrafi zaprojektować odpowiednio system, podzielić na moduły biznesowe i współpracować z ekspertami domenowymi.
Za każdym ****** razem
Problem jest zawsze ten sam. Na początku swojej przygody z programowaniem, prawdopodobnie zadawałeś/aś pytania:
- Gdzie się tego nauczyć?
- Jakie umiejętności powinno się opanować?
- Co trzeba zrobić najpierw?
- Jak długo mi to zajmie? Kiedy dostanę pierwszą pracę?
- Jakie są dobre praktyki? Czy to, czego uczą w tutorialach, jest poprawne?
Ta historia powtarza się z każdą nową dziedziną, którą chcemy poznać. Gdzie znaleźć dobre materiały? W jakiej kolejności powinienem je obejrzeć (jak filmy Star Wars)? Przygotowanie swojej własnej Drogi Jedi, ekhm… programisty nie jest prostym zadaniem. Więc postanowiłem Ci pomóc, młody (nie ważne ile masz lat doświadczenia) Padawanie i większość zrobiłem za Ciebie.
3 lata poszukiwań w jednym miejscu
Tematy związane z DDD zgłębiam nieprzerwanie od około 3 lat. Prawie każdego dnia staram się praktykować oraz czytam nowe posty i książki na ten temat. To była miłość od pierwszego wejrzenia, kiedy podczas zajęć na uczelni (u najlepszego prowadzącego z jakim miałem do czynienia) zobaczyłem wyświetloną na slajdzie okładkę Domain-Driven Design, autorstwa Erica Evansa (tzw. Blue Book) (ale nie polecam jej na początek). Miałem to duże szczęście trafić na praktyka, który miał wiedzę na ten temat. Niestety większość z Was z pewnością nie usłyszałą o tym na studiach.
DDD jest w Twoim DNA
Potem wszystko już poszło z górki - 4Developers, kolejne książki, blogi, szkolenia.
Dodatkowo całą wiedzę usystematyzował mi kurs Droga Nowoczesnego Architekta. Prowadzą go znane autorytety z branży IT: Łukasz Szydło, Jakub Pilimon i Jakub Kubryński. Nad jakością czuwa Maciej Aniserowicz z devstyle.pl. O większości poruszanych zagadnień już słyszałem, ale to, jak jest wszystko przedstawione i układa wiedzę, jest nie do przecenienia. Drogi czytelniku, gdybym miał Ci polecić jeden kurs związany z programowaniem, w który warto zainwestować pieniądze, to jest to właśnie DNA (nie mam z tej szczerej reklamy żadnego profitu).
Nabór do obecnej edycji trwa TERAZ i kończy się ZARAZ (nie wiadomo czy będzie kolejna, a jeżeli będzie, to jak zawsze — za większą cenę). Kupić możesz na stronie: droganowoczesnegoarchitekta.pl Wydawca kursu gwarantuje Ci zawsze miesiąc na zwrot pieniędzy, bez podawania żadnego powodu. Więc czemu nie spróbować? Jeśli Ci się nie udało zdążyć, to na mojej liście mailingowej z pewnością będę Cię informował o kolejnych edycjach i innych kursach, które sam sprawdziłem.
Moja krótka ocena kursu DNA, którą kiedyś wysłałem do Macieja Aniserowicza:
Po prostu, jeżeli z kimś dyskutujesz nad jakąś kwestią programistyczna, albo projektujesz architekturę i wiesz, iż ktoś przerobił DNA, to rozmowa od razu wchodzi na wyższy poziom :) Jak dla mnie to powinien być MUST HAVE w edukacji programistów. Jedyny problem to, na jakim etapie wprowadzać takie zagadnienia. Bo… Po prostu, jeżeli ktoś nie doświadczył pewnych problemów to nie doceni rozwiązań :) Rozmowy rekrutacyjne też są zupełnie inne, jak wiadomo, iż kandydat/rekruter mają pojęcie o kwestiach tam poruszanych. Oczywiście nie muszą robić DNA, żeby to znać, ale taka świadomość już daje pole do rozmowy i pogłębionej dyskusji :) To naprawdę zmienia polskie IT.
Wciąż nie tylko wierzę, ale wiem, iż te techniki mogą ustrzec nas przed wieloma złymi decyzjami i uratować projekty programistyczne. DDD nie jest tylko o wzorcach kodowania, to coś dużo więcej. Najistotniejsza część techniki (strategic patterns) skupia się na poszukiwaniu wspólnego języka z biznesem (wspominany UL), który funkcjonuje w określonej jego części (Bounded Context), przekładaniu go na kod i rozwiązywaniu problemów biznesowych. Rozwiązaniem może być kawałek kodu, ale czasem i proces manualny wykonywany przez panią Krysię z księgowości.
What? Your CODE is evolving!
Praktykując DDD, stajemy się nie tylko klepaczami kodu, ale wartościowymi partnerami dla przedsiębiorców. No bo w programowaniu wiadomo, o co chodzi — o to, co zawsze. 🤑 To zupełnie zmienia Twoje myślenie o tym, czym jest programowanie, a czytelny kod, staje się tylko skutkiem ubocznym (ang. side effect) dobrego designu w myśl DDD. Poniżej możesz zobaczyć, jak mój styl implementacji modelu domenowego ewoluował w międzyczasie — niczym Pokemon, po osiągnięciu odpowiedniego levelu.
BEFORE
Nie zatrzymuj się zbyt długo na tym kawałku kodu. Nie jest łatwo zrozumieć, co tutaj się dzieje.
AFTER
Wraz z DDD komplementarne są metody takie jak Event Storming czy EventModeling. Kod, który zaraz zobaczysz, nie jest już dziełem przypadku. Został przełożony z wymagań opisanych dzięki sticky notes. Koszt oderwania karteczki i napisania innej jest niewspółmiernie mniejszy od kosztu przepisania implementacji.
Reguły biznesowe odkryte na sesji EventStormingu wyglądają tak jak powyżej. Nie pozostaje nic prostszego niż przełożenie ich na kod z wykorzystaniem wzorca Zdarzeń Domenowych (ang. Domain Event).
Odczytanie tego, co dzieje tutaj dzieje, nie powinno Ci sprawiać większego problemu. Nawet jeżeli domena nie jest Ci znana. Mam nadzieję, iż widzisz tutaj reguły biznesowe, które w stylu BDD można by opisać mniej więcej tak:
- Given data deletion is paused, when change maximum retention, then maximum retention should be changed to a new value.
- Given data deletion is not paused, when change maximum retention, then maximum retention should be changed to a new value and data deletion should be paused.
Developer Journey Map
Chcesz dzisiaj zmienić swoje programistyczne myślenie? Przestać widzieć świat w bazach danych i tabelkach a zacząć modelować procesy biznesowe? Przygotowałem dla Ciebie Miro Board z mapą, która poprowadzi Cię przez krainę Domain-Driven Design i innych ważnych zagadnień. Możesz tam znaleźć miejsce, w którym rozpoczniesz swoją podróż już dzisiaj! Jest tem dużo materiałów i źródeł nt. DDD i Event Sourcingu i innych rzeczy wspomnianych w tym wpisie. Odkryjesz też dobre przykładowe projekty, na których warto się wzorować w przyszłości. Mam nadzieję, iż dzięki podążania wg. wyznaczonego na mapie szlaku będziesz z dnia na dzień coraz lepszym Developerem!
MIRO BOARD LINK - Developer Journey Map - DDD & Event Sourcing
Jestem pewien, iż da Ci to solidne podstawy teoretyczne i będzie Twoim kompasem, aby osiągnąć praktyczne mistrzostwo.
Twoja własna przygoda właśnie się rozpoczyna
A może już jesteś na tej drodze? Co sądzisz o tej mapie? Czy masz już inne doświadczenia :) ? Pomogła jakaś zaznaczona na niej pozycja? A może warto coś tam dodać? Daj znać w komentarzach! Będę mapę aktualizował na bieżąco wraz z dokonywaniem kolejnych odkryć, więc wracaj tutaj od czasu do czasu, albo zapisz się na listę mailingową :)
✉️ LISTA MAILINGOWA
Jeśli chcesz dowiedzieć się więcej o DDD i Event Sourcingu, to serdecznie zapraszam Cię na moją listę mailingową. Będziesz nie tylko iść po moich śladach, ale wyruszysz w tę drogę razem ze mną! Do zobaczenia po drugiej stronie maila, czy na grupach DDD, do których zaproszę Cię w jednej z wiadomości. Dla najbardziej aktywnych czytelników będzie też szansa na mentoring ze mną :)
git init 😎 Wchodzę w to!
🇬🇧 English version
If you’d like to share this with your non-polish friends, the similar blogpost is also available in English version. I encourage you to follow me on dev.to
