DDD h4x: stosowalność DDD - czyli czy i kiedy DDD może mi w czymś pomóc

O serii

Niniejszy post jest pierwszym z serii DDD h4x poświęconej specjalnym technikom i hakom stosowanym w DDD.

Ostatnie dwa lata spędziłem na intensywnej pracy związanej głównie z wdrażaniem różnych form DDD w różnych organizacjach (stąd zmniejszona aktywność na blogu). Przymierzając się do zebrania doświadczeń w formie książki postanowiłem podzielić się obserwacjami i przemyśleniami z czytelnikami bloga oraz poddać je dyskusji w celu destylacji esencji.

Doświadczenia pochodzą z różnych aspektów, technicznej implementacji, uczenia technik, ale chciałbym skupić się przede wszystkim na samym modelowaniu.

Podstawowe pytanie: czy i kiedy?

Zaczniemy od podstawowego problemu: stosowalności DDD. Typowe pytania: czy DDD aplikuje się do w moim projekcie, jakie są ryzyka, co będę z tego miał, które problemy (właściwie, to nikt nie przyzna się, że ma problem, więc raczej: wyzwania) adresuje DDD, itd...

Każdy praktyk DDD odpowie Ci mniej więcej w ten sam sposób: stosuj DDD tylko dla systemów, które charakteryzują się znaczącą złożonością logiki domenowej, w których model domenowy jest krytyczny, ponieważ jest np. powodem tworzenia systemu, ponieważ np daje klientowi przewagę nad konkurencją.

Przykładowo: wyrafinowany model pozwala szybciej reagować na zmiany w biznesie, np szybciej definiować nowe produkty, analizować zachowanie klientów itd...

Często jednak zespoły nie posiadają jeszcze intuicji pozwalającej na "zmierzenie" złożoności.
Pojawiają się wówczas bezkontekstowe metryki typu: 30 use casesów (V. Vernon), 300 mandaysów, itd...
Bezkontekstowe metryki mają to do siebie, że są oparte o LWPzD (liczby wyciągnięte prosto z ... yyy dziupli).

Metryki:

Przechodzimy do meritum posta, czyli metryk, które uważam za miarodajne. Zatem, jeżeli zastanawiasz się nad wprowadzeniem DDD, to musisz sobie odpowiedzieć na kilka kluczowych pytań:

1. Jaka jest głębokość systemu? 

Pojęcie "głębokości systemu" jest metaforą, którą stosuję aby zorientować się co system "robi pod maską". Innymi słowy: ile kodu jest pomiędzy interfejsem systemu (graficznie ui lub jedynie api publikowane dla innych systemów) a infrastrukturą techniczną (np. jakimś rodzajem magazynu danych, sterownikami do urządzeń itd).

Przykładowo mamy ekran, klikamy w przycisk "OK" i co dzieje się wówczas "pod spodem". Czy następuje jedynie zebranie danych z  formularza, walidacja, proste kalkulacje i zapis. Jest to system klasy CRUD, czyli potocznie zwana "przeglądarka do bazy danych". System tej klasy charakteryzują się "płytką" (w sensie głębokości) logiką i zapewne nie ma tutaj miejsca na model domeny. Same ekrany są modelem domeny.

Innymi słowy: model mentalny problemu jaku użytkownik ma swej głowie, to co widać na ekranie i schemat bazy danych są tym samym.
Często spotykam się z systemami legacy, gdzie zaczęło się od niewinnej "powłoki wizualnej na relacyjną bazę danych" a w aktualnym stadium mamy do czynienia z agonią kolosa (stojącego na glinianych - bo krudowych - nogach).

Zupełnie inną "głębokość" będzie miał system, w którym przykładowo:
użytkownik klika "zatwierdź zamówienie" a pod spodem system: wylicza rabaty i kary, nalicza prowizje dla handlowców, steruje stanami magazynowymi i produkcją oraz integruję się z SAPem.
Złożoność tej logiki będzie wymagała zapewne nietrywialnego modelu.

2. Jaka jest relacja pomiędzy UI a modelem domenowym?

Na podstawie poprzedniego przykładu możemy sobie wyobrazić, że użytkownik nie maj pojęcia o większości operacji, które wykonują się w systemie gdy klika on przycisk "zatwierdź zamówienie".

Nie ma o nich pojęcia, ponieważ nie chcemy aby miał ich świadomość (szczególnie prowizji dla handlowca;)

3. Kto jest źródłem wiedzy: User czy Ekspert?

Dochodzimy tutaj do kolejnego kluczowego pytania. Tworząc model domeny będziemy rozmawiać z potencjalnymi użytkownikami czy może z kimś zupełnie innym - z kimś, to wie dlaczego system ma działać w ten sposób, ale sam nie koniecznie będzie operatorem systemu. W DDD osoby te grają rolę Ekspertów Domenowych. Oczywiście w szczególnym przypadku Ekspert może być również Operatorem.

Innymi słowy: czy potencjalny operator systemu ma świadomość złożoności biznesu, czy jedynie wykonuje swoje zadania/obowiązki i jest zadowolony z błogiej nieświadomości.

Przykładowo: najstarszy księgowy (Ekspert wydelegowany od strony klienta) objaśnia nam jak i dlaczego działa pewien proces, który modelujemy i implementujemy, ale użytkownik (np super junior consultant) będzie wpisywał na UI jedynie dane i klikał "procesuj'.

Nie chcę być źle zrozumiany: operator systemu jest ważny w całym procesie produkcji systemu, ponieważ jest źródłem wiedzy dla UX designera, który będzie się starał zapewnić mu ergonomię.

W projektach, gdzie nie mamy do czynienia z klientem (zewnętrznym lub wewnętrznym) i tworzymy produkt "na półkę" warto wyłonić rolę Eksperta Domenowego. Chodzi o to, aby aby twórca modelu nie był jednocześnie jedynym źródłem wiedzy o domenie, ponieważ może popaś w pułapkę "miłości do dziecka swego umysłu". Ekspert domenowy powinien być walidatorem modelu - czyli osobą nie będącą twórcą modelu.

4. Czy obiekty sterują światem, czy może są jedynie notatką ze stanu świata?

Na wstępie podziękowania dla jednego z uczestników szkolenia - Rafała O. który ujął tę metrykę zgrabne sformułowanie.

Możemy zadać sobie pytanie, czy obiekty z naszego modelu domenowego mają w sobie zamodelowane reguły sterowania światem zewnętrznym? Podejmują decyzje na podstawie reguł, które wyłoniliśmy podczas sesji modelowania z Ekspertem Domenowym.

Czy może są jedynie strukturami danych (nie obiektami w sensie OO), które są "notatką" na temat pewnego stanu świata zewnętrznego - system CRUD. Użytkownicy używają systemu jedynie do gromadzenia danych i ew. ich edycji, nie istnieją żadne reguły domenowe (jedynie prosta walidacja), zawsze można wszystko przeedytować.

Często pojawiają się pytania: "biznes sam przyznaje, że nie wie jak i dlaczego to ma działać" lub "biznes działa niezgodnie z modelem wynikającym z ustawy". W takim razie nasz model oddaje nie to jak powinno być w idealnym świecie, tylko to jak biznes działa. Chcemy przecież aby nasze procesory robiły to w taki sposób jak chce biznes a nie jak wyglądałoby to w idealnym świecie.

5. Co jest pierwsze: proces czy domena? 

Na ten temat pisałem w jednym z poprzednich postów: http://art-of-software.blogspot.com/2013/10/przyczyna-czy-skutek.html - komentarze są również ważne.

Rozpoczęcie modelowania od domeny a nie od procesu jest najważniejszą różnicą pomiędzy DDD a innymi podejściami. Widać to już podczas pierwszej sesji modelowania lub podczas dwóch pierwszych zadań warsztatowych. Różnice w modelach, które wyłaniają się z tych dwóch podejść są zasadnicze.

Czasem spotykamy się z problemem, gdzie nasze źródło wiedzy domenowej używa narracji z poziomu procesu a nie domeny. Możemy przekierować model mentalny takiej osoby odpowiednimi technikami lingwistycznymi i wizualnymi - o czym w kolejnych postać z serii DDD h4x.

Kluczowe jest też zrozumienie, że duże organizacje dążą do standaryzacji procesów, w celu zapewnienia sobie swobody w wymianie personelu. Zainteresowanych tematyką miękką zapraszam do lektury artykułu poświęconego modelowi rozwoju kompetencji braci Dreyfus: http://bottega.com.pl/artykuly-i-prezentacje#soft
Wniosek płynący z tego modelu jest następujący: na niższych poziomach kompetencji jesteśmy zorientowani na procesy, jedynie Ekspert rozumie dlaczego proces tak wygląda. Dlatego w DDD dążymy do kontaktu z Ekspertem Domenowym.

6. Jak długo będziesz utrzymywać system? 

Stosowanie technik DDD jest kosztowne, dlatego traktujemy je jako inwestycję (lub spłatę długu w systemach legacy).

Rozpoczynając nowy projekt musimy odpowiedzieć sobie na pytanie o perspektywę czasową. Na jej podstawie oceniamy czy warto inwestować czas w model, czy być może metodyka "kroczącego prototypu" będzie bardziej opłacalna.

Warunki dodatkowe

W uproszczonym kontekście możemy stosować podejście DDD Lite - posługujemy się wówczas jedynie wzorcami taktycznymi (building blocks), które zwiększają drastycznie jakość kodu i jego podatność na testowanie.

Natomiast dostęp do Ekspertów Domenowych (będących źródłem wiedzy i weryfikujących modele), wyłonienie roli Modelarza (biegłego w technikach DDD i posiadającego miękkie zdolności predysponującego go do tej roli) oraz podejście iteracyjne pozwalają nam na pełną implementację DDD.

W skali całego systemu

Klasy problemów technicznych

Wymienione metryki sprowadzają się do umiejętności klasyfikowania problemów i dobierania klasy rozwiązania do klasy problemu.
Chodzi tutaj o dobór klasy rozwiązania technicznego jak i metodyki (modelowania, zarządzania projektem).

W dużym systemie mamy zapewne do czynienia ze wszystkimi klasami problemów. Znakomita większość kodu systemu może sprowadzać się klasy problemu CRUD. Jednak kilka/kilkanaście procent może wymagać stosowania DDD.

Od architekta wymagamy umiejętności klasyfikowania problemów i oczekujemy znajomości wielu (a nie tylko jednego) stylów architektonicznych oraz doświadczenia w dobieraniu klasy problemu do klasy rozwiązania.

Trudne pytanie: jak sklasyfikować problem? Czy analiza wymagań niefunkcjonalnych wystarczy? Na pewno nie, dlatego architekt pownien być zaangażowany w modelowanie i implementację aby na podstawie wyłaniającej się złożności (np. głbokość systemu) projektować odpwoiednie rozwiązania.

Klasy problemów organizacyjnych

Podobnie część funkcjonalności mona zakwalifikować:

• eksperyment - nie wiem czego nie wiem
• pośrednie - wiem czego nie wiem
• rzemiosło - wiem wszystko

Czyli: Agile, Lean, Waterfall.

Podejście DDD

W DDD zakładamy, że nie ma sensu (komercyjnego) stosowanie technik DDD na przestrzeni całego systemu. Dlatego wyłaniamy Core Domain (kilka/kilkanaście) procent systemu, gdzie stosujemy te techniki.

W tym miejscu stosujemy odpowiednią architekturę aplikacyjną (4-layers, CqRS, Ports&Adapters), a w innych modułach (crud) lepiej się sprawdzi jedna warstwa z np. mvc/mvp i scafoldingiem.

To w Core Domain inwestujemy w gęstą siatkę bezpieczeństwa testów automatycznych.

DDD krok po kroku - część III

W najnowszym numerze programistamag.pl ukazała się trzecia część naszej serii tekstów poświęconych DDD: "Domain Driven Design krok po kroku Część III: Szczegóły implementacji aplikacji wykorzystującej DDD na platformie Java – Spring Framework i Hibernate"

Tym razem wchodzimy w szczegóły wykorzystania Spring (lub ogólnie: kontenera Inverion of Control oferującego 3 techniki odwracania kontroli: Dependency Injection, Events, Aspect Oriented Programming) i JPA (ogólnie: mapera relacyjno-obiektowego).

//===========================
Zapraszam do dyskusji na temat podejmowanych w tekście decyzji projektowych.

Persystentny Multi-Listener, czyli... Saga

Persystentny multi-listener... jak to pięknie brzmi...:)

Cóż to takiego?

Listener - czy obiekt słuchający zdarzeń,
mulit - czyli chodzi o wiele zdarzeń,
persystentny - czyli posiadający trwały stan.


Podczas ostatnich warsztatów z zakresu projektu DDD-CqRS Leaven wspomniana wyżej technika modelowania czasu spotkała się z zainteresowaniem wielu osób. Nic dziwnego, jest to dosyć nowy pattern; również na szkoleniach wzbudza zawsze największe emocje. Głównie dlatego, że ciężko pogodzić się z myślą, że coś tak złożonego można modelować i implementować w tak prosty i przyjemny sposób:P

Pattern ma swoją oficjalną nazwę, brzmi ona Saga. Jeżeli saga kojarzy się senior developerom z sagą rodziny Carringtonów, to dobrze się Wam kojarzy. Saga to coś co może rozciągać się w czasie niczym telenowela. Saga jest patternem służącym do orkiestracji wielu zdarzeń, które mogą zajść w rozproszonym systemie w nieokreślonej kolejności. Czas pomiędzy zajściem zdarzeń może być relatywnie długi, dlatego należy persystować jej stan w czasie oczekiwania na kolejne zdarzenie.

Przykład:
Wyobraźmy sobie system, w którym mamy moduły: sprzedaży, płatności i magazynu.
W module sprzedaży możemy zatwierdzić obiekt biznesowy Zamówienie. Zamówienie rzuca wówczas zdarzenie biznesowe ZatwierdzonoMnie zawierające id tegoż zamówienia.
W module płatności możemy dokonać wpłaty. Być może jest to przedpłata dokonana wcześniej niż zatwierdzenie zamówienia... Moduł ten rzuca zdarzenie niosące informację o zajściu faktu dokonania wpłaty.
Oba zdarzenia są orkiestrowane przez sagę Zakupy. Jeżeli otrzyma ona oba zdarzenia (pasujące po id biznesowym) i stwierdzi, że jesteśmy "kwita" wówczas może wysłać sygnał do modułu magazynowego aby przygotować paczkę do wysyłki.

Oczywiście możemy tego typu proces zaimplementować w inny sposób niż zdarzeniowy, ale jeżeli zależy nam na decouplingu modułów systemu (wraz z wszystkimi konsekwencjami: skalowanie, testowanie, rozszerzalność, otwartość na dodawanie pluginów, redukcja architektury Speaghetti na poziomie modułów) to warto posłużyć się Sagą.


Udi Dahan dosyć dobrze wyjaśnia motywację oraz szczegóły koncepcyjne: Saga Persistence and Event-Driven Architectures dlatego nie chcę powtarzać, tego co zostało napisane ponad 2 lata temu.

Jak widać w powyższym linku technicznie Saga to złożenie 2 wzorców: Observer i Memento. O ile observera każdy zna choćby z bibliotek graficznych i wszechobecnych tam onClickListenerów, o tyle Memento jest mniej znanym patternem. Jeżeli ktoś oglądał film pt. Memento o człowieku, który miał problem z transferem danych z pamięci podręcznej (kora przed-czołowa) do pamięci długotrwałej (hipokamp) to skojarzenie jest również poprawne. Memento to pattern służący obiektom na wysyłanie do siebie informacji na przyszłość. Tak jak bohater filmu, który zapisywał i tatuował sobie na rękach informacje o tym co należy zrobić w przyszłości:)

Natomiast zainteresowanych szczegółami implementacji Sagi odsyłam do przykładu w projekcie DDD&CqRS Leaven:

• opis: http://code.google.com/p/ddd-cqrs-sample/wiki/DomainDrivenDesignBusinessDeveloperMentalModel#Saga
• kod os strony programisty biznesowego: http://code.google.com/p/ddd-cqrs-sample/source/browse/#svn%2Ftrunk%2Fddd_cqrs-sample%2Fsrc%2Fmain%2Fjava%2Fpl%2Fcom%2Fbottega%2Ferp%2Fsales%2Fsaga
• idea i implementacja silnika Sagi:http://code.google.com/p/ddd-cqrs-sample/wiki/CommandQueryResponsibilitySegregationSystemArchitectMentaModel#Saga_Engine

//=============================================

Jako ciekawostkę dodam, że niektóre szyny komunikatów w .NET wspierają mechanizm Sagi niejako "z pudełka"...
Techniczny komunikat (message) jest traktowany na poziomie logicznym jak zdarzenie (event). Ichnie "Message Driven Beany" reagaujące na wiele zdarzeń to po prostu Sagi. Do tego automatyczne ładowanie i zapisywanie Memento, kończenie albo usypianie sagi oraz drobny szczegół: obsługa współbieżności...
Natomiast my w swym świecie Javy wciąż szukamy uber-frameworka webowego, który daje złudzenie, że każdy system jest CRUDem...

Tydzień segregacji

Zbliżający się tydzień to dwie konferencje:
- 4 Developers
- 33rd Degree

Przygotowałem dla Was prezentację na temat Command-query Responsibility Segregation, którą przedstawię na obu konferencjach.


Poniżej wersja alfa.

Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw on Prezi

Prezentacja zgodnie z najnowszymi trendami nie zawiera zbyt wiele tekstu - całość wymaga akompaniamentu paszczowego.

W świecie Javy mamy ostatnio stagnację (frameworki webowe już nie wychodzą co tydzień, a skoro najnowsze wersja Java EE wyszła rok temu to mamy kilka lat spokoju;). Jest to zatem dobry moment na ostrzenie piły - np zastanowienie się nad podstawami.

Ogólne przesłanie prezentacji: wybór narzędzia i podejścia powinien zależeć od klasy problemu.

W świecie Javy mamy z jednej strony platformę korporacyjną, która była pomyślana jako produkt dla klientów (wytwórców oprogramowania) wielkiej skali. Po nasyceniu tego rynku mamy widoczną zmianę strategii marketingowej i atakowanie małych softwarehousów. Z drugiej strony mamy mnogość rozwiązań typu generator jednowarstwowej aplikacji, którymi próbuje się kusić każdego - nawet duże softwarehousy.

W prezentacji przedstawię rozwiązania architektoniczne podpatrzone w świecie .NET. Nie są one specyficzne dla .NET ale w tej społeczności są mocniej rozwijane i dyskutowane niż w naszej.

Warto podkreślić, że koncepcja architektoniczna CqRS została wypracowana w ciągu kilku ostatnich lat przez community. Nie jest to zatem objawienie zesłane przez anonimowych pracowników jakiejś firmy, lecz wynik dyskusji i eksperymentów nad rzeczywistymi problemami. Jest to zatem owoc pracy ludzi żywo zaangażowanych w sprawę - stąd wartość.


Mottem dla mojej prezentacji będzie ewolucja architektury, czyli jej rozbudowa wraz ze wzrostem skali (komplikacji i wielkości) systemu. Wychodzę z założenia, że nie każde podejście może ewoluować.


Dla zainteresowanych prezentacją mam sugestię: warto wcześniej zapoznać się z moją prezentacją na temat Domain Driven Design. Nie jest to konieczne, ale jeżeli to zrobicie, to całość ułoży się w sumie w spójne rozwiązanie.
Link tutaj.



Tydzień segregacji właściwie zostanie wydłużony...

W kolejnym tygodniu Greg Young będzie prowadził otwarty wykład i 3-dniowe szkolenie na temat DDD i CqRS w Krakowie (szczegóły).

Nieczęsto zdarza się możliwość uczenia od mistrza, tak więc polecam:)




//=================================

Jeżeli ktoś ma uwagi/sugestie odnośnie prezentacji (treść, zakres) to piszcie w komentarzach lub na prv.
Będę bardzo wdzięczny za feedback:)

Greg Young w Polsce! (UWAGA KONKURS)

Mamy już kompletną agendę konferencji 4Developers, zatem mogę oficjalnie powiedzieć, że Greg Young, którego udało się nam zaprosić do Polski, przedstawi dwie prezentacje:

1. Zapomnij o szczegółach, liczy się efekt! - jest to nowa, jeszcze nie publikowana prezentacja, którą Greg przygotował specjalnie dla nas na 4Dev
   
2. Uwolnij swoją domenę! - przekrojowa prezentacja, która udowadnia, że możemy skonstruować wysokowydajny, skalowalny system, zachowując nieautystyczny model domeny biznesowej. Czyli jak połączyć Domain Driven Design, Commmand-query Responsibility Segregation, Event Sourcing oraz kilka innych najnowszych zdobyczy inżynierii oprogramowania.
   

Od siebie dodam, że Greg należy do mojej ścisłej czołówki guru współczesnej inżynierii oprogramowania. Posiada tytuł Most Valuable Person Microsoftu, jest głównych twórcą koncpecji architektonicznej CqRS oraz wniósł duży wkład w rozwój Domain Driven Design. Dodatkowo potrafi z pasją opowiadać historie o zaawansowanych koncepcyjnie technikach, w taki sposób, że doznajemy efektu "I know Kung Fu".



btw: czy ktoś z Was odważyłby się wystąpić ze slajdami w TAKIM stylu: 7 Reasons DDD Projects #FAIL



//=========================

KONKURS

Rejestracja na 4Dev będzie trwać już tylko do końca marca, a dla czytelników bloga mamy niespodziankę w postaci darmowej wejściówki.

Zasady są proste: wygrywa osoba o największej ilości komentarzy pod postami na moim blogasku. Chodzi oczywiście o posty wystawione przed ogłoszeniem konkursu:0 Zgłoszenia wraz z linkami do komentowanych postów przysyłajcie na maila podanego w sekcji "o mnie".

Proszę o udział tylko tych z Was, których potencjalne szanse na przybycie na konferencję wynoszą 99% (obecność sprawdzę osobiście;)

Undergroundowy Domain Driven Design

"Kraków - dawna stolica Polaków"

W sobotę odbyła się w Krakowie konferencja 4develoeprs, na której to byłem miałem (że pozwolę sobie napisać w staropolskiej składni zaprzeszłej będąc natchnionym pobytem w mieście poetów i masakrycznych dziur w asfalcie) przyjemność przedstawić krótką prezentację.

Tym, którzy zastanawiają się jakim cudem pojawiłem się na salonach obok takich znamienitości jak Adam Bien czy Neal Ford śpieszę wyjaśnić iż chodzi o Java Underground.

JU, którego organizatorem był Grzegorz Duda polegał (w skrócie) na przedstawieniu prezentacji w ciągu 5 minut, a brali w nim udział: Adam Bien (EJB), Bartek Kuczyński (JavaFX), Szymon Jachim (Scala), Bartek Chrabski (Jazz) no i ja (o Jacku L. który nie dotarł nie wspomnę;)

Aby zmieścić się w konwencji jako temat wybrałem sobie pewne "undergroundowe" aspekty architektury pojawiające się w DDD. Jako, że temat spotkał się z pewnym zainteresowaniem, a ja w ciągu pięciu minut byłem w stanie wydobyć z siebie jedynie turbo-bełkot, rozwinę w tym poście nieco bardziej każdy ze slajdów.



O ile samo podejście DDD nie jet już undergroundem to implikacje wynikające z podążania za nim można już do undergroundu zaliczyć. Ortodoksyjne przestrzeganie zasad DDD prowadzi do pojawienia się na poziomie projektu i implementacji pewnych konstruktów, które mogą się wydawać obrazoburcze, szczególnie w porównaniu z tradycyjnym podejściem, lansowanym przez różnego rodzaju frameworki w różnego rodzaju tutorialach.



No więc właśnie... silnie zakorzeniona tradycja każe umieszczać algorytmy w procedurach a dane w strukturach danych.



Źródła tej tradycji sięgają co najmniej szalonych lat '70 (pewnie i wcześniej), kto programował w turbo pascalu ten zapewne widzi analogię pomiędzy servisami a procedurami oraz encjami a rekordami.

Tradycja proceduralna jest mocno ugruntowana i nie można jej kwestionować. Doskonale nadaje się do modelowania tych domen, które z natury są proceduralne. Niestety nie sprawdza się zbyt dobrze w przypadku problemów z domen o naturze obiektowej.

Warto zastanowić się dobrze w początkowej fazie projektu nad naturą domeny. Nie warto walczyć z naturą - nikt jeszcze tej walki nie wygrał. Wszyscy wiemy czym kończy się proceduralne podejście stosowane do skomplikowanych (nie znaczy dużych!) domen... Prędzej czy później pojawia się ON. Wyłania się z plątaniny zależności i powielonej logiki... Przeklęty demon... Potwór Spaghetti.

Właściwie to w klasycznym podejściu będzie to Potwór Lasagne (Spaghetti z warstwami;)



Koncepcja DDD pojawiła się jako odpowiedź na problemy z komplikacją logiki biznesowej. DDD zakłada, że warstwa logiki domenowej jest najważniejszym elementem systemu i jednocześnie najtrudniejszym do opracowania. Jest to serce systemu, ale serce bardzo kruche. Niepoprawny model nie jest odporny na zmiany (której jak wiemy z doświadczenia są pewne jak śmierć i podatki - podatki to chyba nie u nas).

DDD nie jest żadną technologią, platformą ani frameworkiem. Jest to jedynie zbiór zasad, wytycznych, wzorców i dobrych praktyk, których stosowanie ma zapewnić zaprojektowanie porządnego modelu domeny.

DDD to dosyć obszerna "filozofia", natomiast na potrzeby przykładów undergroundowych architektur zobaczymy tylko mały jej fragment. Przy okazji warto przypomnieć, że DDD aplikuje się raczej do złożonych problemów. Pytanie tylko, kto potrafi przewidzieć gdzie zabrnie projekt - już parę razy spotkałem się z projektami, które na początku wydawał się "szybką akcją bydgoskiej milicji". Nota bene: proste problemy powinno rozwiązywać się chyba w Excelu; ostatecznie w Accesie;) Ale jeżeli już czujemy silną wewnętrzną potrzebę aby wydurniać się z programowaniem prostych problemów i nie chcemy robić tego proceduralnie to zawsze można skorzystać z podejścia DDD Lite.



DDD tak na prawdę nie jest niczym nowym. To po prostu zestaw dobrych praktyk opartych na starych dobrych (ale nie tak starych i nie tak dobrych jak Turbo Pascal;) koncepcjach obiektowej analizy i projektowania. Wystarczy po prostu ich nie negować i nie programować wbrew nim - a jest to konieczne aby osiągnąć pewien cel...

DDD zakłada unifikację modelu analitycznego i projektowego, o którym już pisałem: UP-DDD in Action: Malutka Teoria Unifikacji. Cały zespół, począwszy od analityków, poprzez projektantów aż po koderów powinien posługiwać się wspólnym językiem opisującym domenę - zwanym w DDD Ubiquitous Language. Niestety aby było możliwe dosłowne zaprojektowanie pomysłów analityka musimy posługiwać się pełnym wachlarzem środków wyrazu języków OO. Procedury i encje nie wystarczą - o tym dalej przy okazji archetypów.




DDD zakłada modelowanie warstwy logiki domenowej przy użyciu pewnych standardowych klocków, zwanych Building Blocks. Jest to jedna z głównych koncepcji. Na pierwszy rzut oka może się wydawać, że jest ich całkiem dużo, ale każdy ma uzasadnienie swego istnienia wynikające z koncepcji Responsibility Driven Design, o której pisałem.



Artefakty już opisywałem, więc jedynie gwoli przypomnienia:

• Encje w DDD nie są tym samym czym czym w standardowym podejściu. Encje modelują biznes więc posiadają odpowiedzialność - metody biznesowe.
  
• Servisy w DDD nie są tym samym czym czym w standardowym podejściu. Serwisty z tej warstwy enkapsulują logikę, której nie można w sensowny sposób przypisać do odpowiedzialności żadnej z encji.
  
• Repozytorium jest abstrakcją persystencji - pamiętajmy, że w nietrywialnych projektach części agregatów (grafów encji) mogą pochodzić z różnych źródeł (np część z bazy, część z web servisu, a inna część z LDAP)
  

W ortodoksyjnym podejściu encje nie posiadają nawet getterów i setterów. To jest totalny underground w porównaniu z klasyką. Niewielu programistów potrafi to zaakceptować i dla tego chowają się za murem dysonansu kognitywnego.

Pewnie zastawiasz się: jeżeli nie ma nawet getterów/setterów to w jaki sposób wyświetlić encję na formularzu? Albo jak ją zmienić? Odpowiedź już niedaleko...



Nieograniczanie się do anemicznych (pozbawionych odpowiedzialności) encji oraz prymitywnych servisów ma kolejną niebagatelną zaletę. Posługiwanie się bogatym zestawem Building Blocks oraz korzystanie z bogactwa technik OO pozwala niemal dosłownie implementować zaawansowane i złożone modele analityczne. Na przykład modele wyprowadzone z archetypów. O archetypach już w niedalekiej przyszłości pojawię się parę postów na tym blogu, ponieważ IMHO jest to zdecydowanie ważniejsze niż kolejny gówniany framework webowy.

Póki co przyjrzyjmy się przykładowemu modelowi użytkowników na powyższym slajdzie... Piękny, prawda? Niestety nadaje się jedynie na przykłady w książkach lub jako model w projektach "Hello World".



Chcąc nieco bardziej profesjonalnie zaprojektować model np. użytkowników możemy
a) pomyśleć - co nie gwarantuje sukcesu
b) skorzystać z archetypu o nazwie "party" ("uczestnik", nie "impreza")

Tak jak wspomniałem o archetypach będzie później, ale zwróćmy uwagę na (pozorną) komplikację powyższego modelu. Jest fajny, ponieważ można w nim przedstawić dowolną relację pomiędzy dowolnymi uczestnikami (np ja mogę być klientem jakiejś firmy jak i jej pracownikiem; firma ta może być klientem mojej żony; itp).

Ale życzę powodzenia implementując ten (czy inny) zaawansowany archetyp przy pomocy klasycznego podejścia - anemicznego modelu. Widzicie już oczyma wyobraźni te łańcuszki 15 kropek i getterów - train wreck.

Z wykorzystaniem technik DDD możemy w sposób naturalny (OO) i bezproblemowy zaimplementować ten model a całą komplikację ukryć w hermetycznym agregacie (grafie encji), który operuje na swej wewnętrznej skomplikowanej strukturze poprzez metody biznesowe.



Undergroundowe w DDD jest również podejście do zależności. Otóż zależności na poziomie tej samej warstwy nie są niczym złym. Przecież zależności odzwierciedlają model biznesu, więc nie ma potrzeby aby się wydurniać z wstrzykiwaniem zależności czy tworzeniem na siłę interfejsu dla każdego komponentu biznesowego. Wiem, że niektóre platformy od niedawna;) obsługują Wstrzykiwanie Zależności i wymagają wszędzie interfejsów, ale do wszystkiego trzeba podejść z rozsądkiem.

Natomiast zależności modelu domenowego od klas infrastruktury są niepożądane. Nawet gdy klasy te są przykryte interfejsem - to nic nie zmienia, może co najwyżej poprawia nam samopoczucie.

Jedyna techniczną zależność modelu biznesowego jaką dopuszcza DDD jest zależność od szyny komunikatów. Obiekt biznesowy w momencie, gdy poczuje taką potrzebę może co najwyżej stworzyć komunikat i puścić go do pipe (która zawiera zwykle filtry). Jest to architektura pipeline.



Klasyczne podejście warstwowe również nie sprawdza się zbyt dobrze w przypadku DDD. Na powyższym slajdzie widzimy 2 możliwości:

Możemy "podpinać" obiekty biznesowe (te, które mają jakiś stan) pod GUI. Niestety wiąże się to z pewną niezręcznością: GUI "widzi" metody biznesowe. Poza tym obiekty biznesowe muszą oferować gettery i settery w celu dokonywania modyfikacji na nich. Niestety narusza to obiektowy paradygmat enkapsulacji, czyli prowadzi do pornografii obiektowej - odkrywania wewnętrznych struktur.

Podejście to ma jeszcze jedną wadę. Implementowanie setterów pozwala na istnienie obiektu w stanie niespójnym. Przykładowo zmieniając setterami encję Adres możemy zmienić miasto ale nie zmieniać kodu pocztowego:P
Mimo tych wad, podejście tego typu jest często stosowane w "prostych" przypadkach.


Strzałka po prawej stronie diagramy prezentuje inne podejście. W warstwie aplikacji obiekty biznesowe są przepakowywane do/z obiektów transportowych DTO. Wiem, że przepakowywanie obiektów kojarzy się z robotą szympansa, ale dzięki temu możemy uniknąć powyższych wad i niezręczności. Zaraz zaraz... jak pobrać stan obiektu biznesowego gdy nie ma on getterów? Myśl obiektowo; nie pytaj, wydawaj rozkazy! Oto rozwiązanie.

Podejście opierające się na przepakowywaniu ma jednak wadę polegającą na tym, że zupełnie niepotrzebnie pobieramy z repozytorium nadmierną ilość danych - ponieważ dany obiekt transferowy (potrzebny w danym przypadku użycia np. dla danego ekranu) może potrzebować znacznie mniej danych niż zawiera np agregat.



O ile powyższe podejścia do warstw są zadowalające, to prawdziwy underground pojawia się gdy uznamy, że jeden wymiary (wysokość warstw) nie wystarcza i potrzebujemy drugiego - heh to stary trik fizyków. Gdy brakuje im wymiarów aby upchać swe teorie to zakładają istnienie nowych -stąd w różnych odmianach Teorii Strun 11 a nawet 26 wymiarów czasu i przestrzeni;P

Ortodoksyjna architektura DDD wymaga istnienia 2 stosów. Jeden do "prymitywnych" operacji CRUD, drugi natomiast do obsługi rozkazów dla modelu domenowego. Podejście to zapewnia nam utrzymanie eleganckiego stylu Command-Query Separation. Stylu w którym polecenia odczytu stanu i polecenia zmiany stanu są jasno i przejrzyście odseparowane. Posiadanie osobnych klas manipulacyjnych stanem pozwala łatwo audytować i kontrolować ten kod.

Zauważmy, że stos DDD jest tylko do zapisu. Dokonujemy w nim zmian wysyłając komunikaty z poleceniami (wzorzec command). Obiekty biznesowe mogą ew. wygenerować swoje komunikaty i umieścić je w pipeline. Natomiast klient może odpytać o stan jedynie poprzez stos CRUD wysyłając komunikat z kwerendą.

Dodatkowo stos CRUD może zwracać Encje (nie biznesowe a anemiczne - czyli "normalne") będące obiektami transferowymi "szytymi" na miarę.

Separacja przetwarzania logiki od magazynu danych pozwala tworzyć architektury przygotowane na masowe obciążenie i skalowanie - DDDD (4xD to nie pomyłka, ale Distributed DDD). Architektury, gdzie liczy się coś więcej niż procedury i encje. Architektury, w których 2 stosy odpowiadają za osobne moduły z osobnymi magazynami danych w szczególności. Magazynami, które mogą być optymalizowane względem czasu wykonania (stos Command) i czasu wykonywania przekrojowych raportów (stos Query). Magazyny, które mogą asynchronicznie się komunikować i synchronizować.

Ale to temat na osobnego posta... Zainteresowanym polecam wywiad z Gregiem Youngiem - jednym z guru DDD.

//=========================

Tak wyglądają lekkie modyfikacje standardowych architektur warstwowych dopasowane do DDD i DDDD. W świecie Javy jest to jeszcze underground...

Ostatnią z prezentacji, która zakończyła moją sesję na 4developers była "Understanding Distributed Messaging Systems and Where They Fit" Raymonda Lewallena
ze ścieżki .NET.

Raymond opowiadał o podstawowych architekturach dużych i skalowalnych systemów rozproszonych opartych o komunikaty. Jakież było moje zdziwienie gdy Raymond wspomniał nagle coś o Agregacie, później o tym, że wysyła on komunikat do pipleina aż wreszcie zobaczyłem diagram architektury 2-stosowej. Dla niego było to takie oczywiste i naturalne, że używa DDD... nawet o tym nie wspomniał i nie robił żadnego wprowadzenia... po prostu standard:)

Chyba chłopaki od .NET wiedzą w co się bawić;P