Projekt nie jest tylko tym, jak rzecz wygląda i jakie sprawia wrażenie. Projekt opisuje to, jak ona działa. // Steve Jobs Pracując nad oprogramowanie
Projekt nie jest tylko tym, jak rzecz wygląda i jakie sprawia wrażenie. Projekt opisuje to, jak ona działa. // Steve Jobs

Pracując nad oprogramowaniem, staramy się, by było ono wysokiej jakości. Pewną jakość osiągamy poprzez zastosowanie testów, które pomagają nam dostarczać oprogramowanie z olbrzymią liczbą błędów. Jednakże, nawet jeśli moglibyśmy stworzyć oprogramowanie zupełnie wolne od błędów, samo to niekoniecznie oznacza, że zaprojektowany model oprogramowania jest wysokiej jakości. Model oprogramowania — sposób, w jaki oprogramowanie wyraża rozwiązanie poszukiwanego problemu biznesowego — w dalszym ciągu może mieć istotne wady. Dostarczanie oprogramowania z małą liczbą defektów jest oczywiście dobre. Mimo to możemy sięgnąć wyżej — po dobrze zaprojektowany model oprogramowania, który jawnie odzwierciedla zamierzony cel biznesowy — a nasza praca może nawet osiągnąć poziom doskonały. Podejście rozwoju oprogramowania określane jako Domain-Driven Design, albo DDD, istnieje po to, by było nam łatwiej odnieść sukces w tworzeniu wysokiej jakości projektów modelu oprogramowania. Jeśli metodyka DDD zostanie prawidłowo zaimplementowana, pomaga osiągnąć punkt, w którym nasz projekt dokładnie prezentuje sposób, w jaki działa oprogramowanie. Celem tej książki jest udzielenie czytelnikom pomocy w prawidłowej implementacji DDD. Może DDD jest dla Ciebie zupełną nowością. Być może już próbowałeś posłużyć się DDD i przychodziło Ci to z trudem, a może wcześniej skutecznie zastosowałeś tę metodykę. Niezależnie od okoliczności bez wątpienia czytasz tę książkę dlatego, że chcesz poprawić swoje umiejętności implementacji DDD — i możesz to osiągnąć. „Mapa drogowa” rozdziału pomoże Ci zaspokoić Twoje specyficzne potrzeby. (...)   Czego powinieneś oczekiwać od DDD? Nie jest to trudny, skomplikowany, ceremonialny proces, który blokuje drogę do postępów. Zamiast tego oczekuj stosowania zwinnych technik projektowania, którym prawdopodobnie już zaufałeś. Poza tym przygotuj się na poznanie metod, które pomagają zyskać głęboki wgląd w Twoją dziedzinę biznesową. Jednocześnie dają perspektywę stworzenia modeli oprogramowania, które są testowalne, elastyczne, uważnie zorganizowane i starannie wykonane. Są po prostu wysokiej jakości. DDD daje nam narzędzia zarówno do modelowania strategicznego, jak i taktycznego. Narzędzia te są konieczne do projektowania wysokiej jakości oprogramowania, które spełnia podstawowe cele biznesowe.   Czy mogę zastosować DDD?   Możesz zastosować DDD, jeżeli masz:

  • pasję do tworzenia doskonałego oprogramowania codziennie oraz upór, by osiągnąć ten cel;
  • gorliwość do nauki i osiągania postępów oraz hart ducha, aby przyznać się do tego, że jest Ci to potrzebne;
  • zdolności do rozumienia wzorców oprogramowania oraz sposobów ich prawidłowego stosowania;
  • umiejętności i cierpliwość do odkrywania alternatywnych projektów z wykorzystaniem sprawdzonych zwinnych metod wytwarzania oprogramowania;
  • odwagę do stawiania wyzwań stanowi istniejącemu;
  • pragnienie zwracania uwagi na szczegóły i umiejętność ich dostrzegania oraz upodobanie do eksperymentowania i odkrywania;
  • motywację do szukania sposobów na lepsze i bardziej inteligentne kodowanie.

  Nie chcę powiedzieć, że krzywa nauki nie istnieje. Mówiąc otwarcie, krzywa nauki bywa stroma. Pomimo to niniejsza książka powstała, aby pomóc spłaszczyć tę krzywą tak bardzo, jak to możliwe. Moim celem jest udzielenie czytelnikowi i jego zespołowi pomocy w zastosowaniu metodyki DDD oraz zmaksymalizowaniu szans na odniesienie sukcesu. DDD przede wszystkim nie dotyczy technologii. Podstawowe zasady DDD to: dyskusja, słuchanie, zrozumienie, odkrywanie i wartość biznesowa — wszystko po to, aby scentralizować wiedzę. Jeżeli masz zdolność rozumienia biznesu, w którym działa Twoje przedsiębiorstwo, to zgodnie z planem minimum możesz uczestniczyć w procesie odkrywania modelu oprogramowania w celu stworzenia Języka Wszechobecnego. Oczywiście będziesz musiał nauczyć się o biznesie więcej — znacznie więcej. Mimo to jesteś na dobrej drodze do odniesienia sukcesu z DDD, ponieważ potrafisz rozumieć pojęcia swojego biznesu podczas rozwijania oprogramowania, a to tworzy właściwą podstawę do zastosowania DDD w całym procesie. Czy posiadanie wieloletniego doświadczenia w rozwoju oprogramowania jest pomocne? Być może. Niemniej jednak doświadczenie w rozwijaniu oprogramowania nie daje zdolności słuchania i uczenia się od ekspertów dziedziny — ludzi, którzy wiedzą najwięcej na temat obszarów biznesu o wysokim priorytecie. Najwięcej można skorzystać z rozmów z osobami, które rzadko używają technicznego żargonu (lub nigdy tego nie robią). Trzeba nauczyć się uważnie ich słuchać. Trzeba uszanować ich punkt widzenia i zaufać, że znają temat znacznie lepiej niż my sami.

Zaangażowanie ekspertów dziedziny przynosi duże korzyści Można dużo skorzystać na rozmowach z osobami, które rzadko używają technicznego żargonu (lub nigdy tego nie robią). Nie tylko Ty będziesz uczył się od nich. Istnieje duże prawdopodobieństwo, że oni także będą uczyli się od Ciebie.

Jedną z bardziej wartościowych cech DDD jest to, że eksperci dziedziny również muszą posłuchać Ciebie. Jesteście członkami tego samego zespołu. Chociaż może się to wydawać dziwne, eksperci dziedziny nie wiedzą wszystkiego o swoim biznesie i oni też powinni dowiedzieć się o nim więcej. Nie tylko Ty będziesz się uczył od nich. Istnieje duże prawdopodobieństwo, że oni także będą uczyli się od Ciebie. Twoje pytania o to, co oni wiedzą, najprawdopodobniej spowodują również odkrycie tych obszarów, które nie są im znane tak samo dobrze. Będziesz bezpośrednio zaangażowany w pomoc wszystkim osobom w zespole w zdobywaniu głębszego zrozumienia biznesu — można nawet powiedzieć: kształtowania biznesu. To wspaniale, kiedy zespół uczy się i rozwija razem. Jeżeli dasz temu szansę, metodyka DDD to umożliwi.

Nie mamy ekspertów dziedziny Ekspert dziedziny to nie jest tytuł zawodowy. Ekspertami dziedziny są ludzie, którzy bardzo dobrze znają obszar biznesu, w którym pracujesz. Często mają oni obszerną wiedzę w dziedzinie biznesowej. Zazwyczaj są to projektanci produktu albo osoby z działu sprzedaży. Nie zwracaj uwagi na nazwy stanowisk. Poszukiwani przez Ciebie ludzie o dziedzinie, w której pracujesz, wiedzą więcej niż ktokolwiek inny i na pewno znacznie więcej niż Ty. Znajdź ich. Posłuchaj. Naucz się czegoś od nich. Uwzględnij ich zdanie w projekcie kodu.

Dotychczas osiągnęliśmy gotowość do spokojnego startu. Nie chciałbym jednak powiedzieć, że umiejętności techniczne są nieważne — że są czymś, bez czego można się obyć. Trzeba się zapoznać z zaawansowanymi pojęciami z zakresu modelowania dziedziny w oprogramowaniu. Nie oznacza to jednak, że będziemy zmuszeni robić coś, co jest ponad nasze siły. Jeśli Twoje umiejętności mieszczą się gdzieś pomiędzy wiedzą z książki Head First Design Patterns  a oryginalną zawartością pozycji Design Patterns lub jeśli znasz bardziej zaawansowane wzorce, to masz naprawdę duże szanse na odniesienie sukcesu z DDD. Możesz na to liczyć. Będę robił wszystko, co w mojej mocy, aby stało się to możliwe. Będę się starał „obniżać poprzeczkę”, niezależnie od tego, jaki jest wyjściowy poziom doświadczenia czytelnika.

Co to jest Model Dziedziny? To model oprogramowania bardzo określonej dziedziny biznesowej, w której pracujesz. Często jest on zaimplementowany jako model obiektowy, w którym obiekty zawierają zarówno dane, jak i zachowania w harmonii z dokładnym znaczeniem biznesowym. Stworzenie unikatowego, uważnie zaprojektowanego Modelu Dziedziny, stanowiącego sedno podstawowej, strategicznej aplikacji albo podsystemu, ma zasadnicze znaczenie dla stosowania metodologii DDD. Dzięki użyciu DDD Modele Dziedziny będą mniej rozbudowane i bardzo skoncentrowane. Stosując DDD, nigdy nie próbujemy zamodelować całego przedsiębiorstwa biznesowego w pojedynczym, olbrzymim Modelu Dziedziny. To jest dobre!

Aby odnieść sukces z DDD, będziesz musiał się czegoś nauczyć. Będzie dużo tego czegoś. Nie powinno to być jednak trudne. Jesteś mądry i musisz uczyć się przez cały czas. Pomimo wszystko każdy z nas musi sprostać następującemu wyzwaniu:  

Osobiście jestem zawsze gotowy, by się uczyć, chociaż nie zawsze lubię, gdy ktoś mnie poucza. //  Sir Winston Churchill

Ta książka ma właśnie taki cel: starałem się, by nauczanie było tak przyjemne, jak to możliwe, i by zapewniało wiedzę niezbędną do skutecznego zastosowania technik DDD. Czytelnik mógłby jednak postawić pytanie: „Dlaczego należy stosować DDD?”. To dobre pytanie.   Dlaczego należy stosować DDD? Właściwie już wcześniej podałem kilka dobrych powodów, dla których zastosowanie DDD ma tak bardzo praktyczny sens. Ryzykując złamanie zasady DRY (ang. Don’t Repeat Yourself — dosł. nie powtarzaj się), ponownie przytoczę je w tym miejscu oraz dodam do nich kilka nowych powodów. Czy ktoś słyszał echo?

  • Umieść ekspertów dziedziny i deweloperów na tym samym poziomie. Dzięki temu wytworzone oprogramowanie będzie miało sens także dla ludzi biznesu, a nie tylko dla koderów. Nie oznacza to jedynie tolerowania przeciwnej grupy. Oznacza stworzenie jednego spójnego i zwięzłego zespołu.
  • Fraza „ma sens dla ludzi biznesu” oznacza zainwestowanie w biznes poprzez stworzenie oprogramowania, które maksymalnie będzie przypominać system, jaki stworzyliby biznesowi liderzy i eksperci dziedziny, gdyby sami byli koderami.
  • Możemy nauczyć wszystkich członków zespołu więcej o biznesie. Żaden ekspert dziedziny, żaden menedżer szczebla C, nikt i nigdy nie wie wszystkiego na temat biznesu. Poznawanie biznesu jest stałym procesem odkrywania, który z czasem staje się coraz bardziej wnikliwy. Dzięki zastosowaniu DDD wszyscy się uczą, ponieważ każdy coś wnosi do odkrywczych dyskusji.
  • Centralizowanie wiedzy ma znaczenie kluczowe, gdyż dzięki temu można zagwarantować, że rozumienie oprogramowanie nie będzie zamkniętą „wiedzą plemienną”, dostępną tylko dla kilku wybrańców — zazwyczaj deweloperów.
  • Nie ma niepotrzebnych tłumaczeń przekazu pomiędzy ekspertami dziedziny, deweloperami oprogramowania a oprogramowaniem. Nie oznacza to, że istnieje kilka tłumaczeń. Oznacza to dokładnie zero tłumaczeń, ponieważ zespół rozwija wspólny język, którym posługują się wszyscy jego członkowie.
  • Projekt jest kodem, a kod jest projektem. Projekt opisuje to, jak system działa. Poznawanie najlepszych projektów kodu następuje poprzez szybkie doświadczalne modele tworzone z wykorzystaniem zwinnych procesów odkrywania.
  • Metodologia DDD dostarcza solidnych technik rozwoju oprogramowania, które dotyczą projektu zarówno na poziomie strategicznym, jak i taktycznym. Projekt strategiczny pomaga nam zrozumieć, co stanowi najważniejszą inwestycję w oprogramowanie, jakie istniejące zasoby oprogramowania można wykorzystać, aby zrealizować ją najszybciej i najbezpieczniej, oraz jakie osoby powinny być w nią zaangażowane. Projekt taktyczny pomaga w utworzeniu pojedynczego, eleganckiego modelu rozwiązania z wykorzystaniem przetestowanych bloków budulcowych oprogramowania.

  Tak jak każda dobra inwestycja, która ma przynieść duże korzyści, z zastosowaniem metodologii DDD wiążą się pewne początkowe koszty dotyczące czasu i wysiłków zespołu. Biorąc pod uwagę typowe wyzwania, jakie napotykamy w każdym przedsięwzięciu związanym z rozwojem oprogramowania, potrzeba inwestowania w solidną metodologię wytwarzania oprogramowania wydaje się szczególnie ważna. (...) W jaki sposób pomaga DDD? DDD jest podejściem do rozwijania oprogramowania, które skupia się na następujących trzech najważniejszych aspektach:

  1. DDD łączy ze sobą ekspertów dziedziny i deweloperów oprogramowania, stawiając przed nimi zadanie wytwarzania oprogramowania, które odzwierciedla model mentalny ekspertów biznesowych. Nie oznacza to skoncentrowania wysiłków na modelowaniu „rzeczywistego świata”. Zamiast niego DDD dostarcza model, który jest najbardziej przydatny dla biznesu. Czasami przydatne i realistyczne modele przenikają się wzajemnie, ale do momentu, w którym te modele się rozchodzą, DDD stosuje model najbardziej użyteczny.Biorąc pod uwagę ten cel, eksperci dziedziny i deweloperzy oprogramowania wspólnie rozwijają Język Wszechobecny tych obszarów biznesu, które są modelowane. Język Wszechobecny jest rozwijany przy akceptacji całego zespołu. Członkowie zespołu porozumiewają się nim i jest on bezpośrednio uwzględniony w modelu oprogramowania. Warto powtórzyć, że zespół składa się zarówno z ekspertów dziedziny, jak i deweloperów oprogramowania. Nigdy nie jest tak, że są „my” i „oni”. Zespół to zawsze my. To jest kluczowa wartość biznesowa, która pozwala przetrwać specjalistycznej wiedzy biznesowej dłużej, niż trwają stosunkowo krótkie początkowe prace rozwojowe związane z kilkoma pierwszymi wersjami oprogramowania. Wiedza ta trwa także dłużej, niż istnieją zespoły, które to oprogramowanie wytworzyły. To jest element, który udowadnia, że koszt rozwoju oprogramowania jest uzasadnioną inwestycją biznesową, a nie tylko zwykłym kosztem.Podejmowany wysiłek jednoczy ekspertów dziedziny, którzy początkowo nie zgadzają się ze sobą albo nie mają podstawowej wiedzy z zakresu dziedziny. Co więcej, praca nad oprogramowaniem wzmacnia spójność zespołu dzięki rozpowszechnianiu obszernej wiedzy dziedzinowej wśród wszystkich członków zespołu, w tym deweloperów oprogramowania. Wysiłki projektowe można uznać za szkolenie mówiące o tym, że każda firma powinna inwestować w swoich pracowników sektora wiedzy.
  2. DDD zajmuje się strategicznymi inicjatywami biznesu. Chociaż to strategiczne podejście do projektowania w naturalny sposób zawiera analizę techniczną, to w większym stopniu skupia się na strategicznym kierunku biznesu. Pomaga to zdefiniować najlepsze wewnątrzzespołowe relacje organizacyjne i dostarcza system wczesnego ostrzegania, pozwalający rozpoznać sytuacje, w których określona relacja mogłaby spowodować niepowodzenie oprogramowania, a nawet całego projektu. Celem technicznych aspektów projektowania strategicznego jest czytelne wytyczenie granic systemów i obszarów biznesowych, co pozwala chronić wszystkie usługi na poziomie biznesu. To dostarcza istotnych motywów do osiągnięcia ogólnej architektury ukierunkowanej na usługi lub architektury sterowanej względami biznesowymi.
  3. DDD wychodzi naprzeciw rzeczywistym technicznym wymaganiom oprogramowania poprzez wykorzystanie narzędzi projektowania taktycznego do analizy i rozwoju wykonywalnych produktów oprogramowania. Narzędzia projektowania taktycznego pozwalają deweloperom produkować oprogramowanie, które jest poprawną kodyfikacją mentalnego modelu ekspertów dziedziny. Jest ono wysoce testowalne, mniej podatne na błędy (tworzy twierdzenie, które da się udowodnić), zgodne z umowami dotyczącymi zapewnienia jakości usług (SLA) i skalowalne, a także umożliwia wykonywanie rozproszonych obliczeń. Ogólnie rzecz biorąc, najlepsze praktyki DDD dotyczą kilkunastu wysokopoziomowych aspektów architektury oraz niższych poziomów projektu. Główny akcent kładą one na rozpoznawanie rzeczywistych reguł biznesowych i niezmienników danych oraz na ochronę przed występowaniem błędów.

Stosowanie tego podejścia w rozwoju oprogramowania pozwala wszystkim członkom zespołu skutecznie dostarczać rzeczywistą wartość biznesową.  


  Fragment pochodzi z książki "DDD dla architektów oprogramowania" Vaughna Vernona, Wyd. Helion 2016. Strona książki >>