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ę.
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.
8 komentarzy:
Siemka, dzida na dobry początek:)
"Same ekrany są modelem domeny"
A w prelekcji "Model jest wszystkim (...)" twierdziłeś coś dokładnie przeciwnego. To tak pół żartem, bo oczywiste, że myślenie ewoluuje.
1. O EKSPERCIE DOMENOWYM
DDD opiera się na założeniu, że masz w biznesie ludzi (ludzia), którzy posługują się konsekwentnie Ubiquitous Language oraz modelem swojego rzeczywistego biznesu. W miażdżącej większości przypadków tak nie jest.
Patrząc na biznes z perspektywy zespołu, moja obserwacja jest taka: to zespół rozkminia, jak działa biznes. Współpracując z różnymi jego przedstawicielami, z których każdy ma swoją własną narrację tego, co się dzieje, po jakimś czasie zespół buduje jakąś tam generalizację tego, jak ten biznes działa. Tworzy więc własny model biznesu (swoje zrozumienie tego modelu).
Nie jest to rzecz jasna ten "prawdziwy" model z głów biznesu, lecz mozaika faktów, domysłów i wyobrażeń. Co do funkcjonalności wymagania biznesu są spełnione, co do modelu nie są. To bardzo, ale to bardzo wyraźnie widać w kodzie w:
* dużej ilość parametrów metod (brak pojęć do nazywania)
* nazwach klas miksujących różne terminy w domenie
* ciałach metod, w których opis biznesowy miesza się z opisem technicznym, co natychmiastowo powiększa wskaźnik CC
Jeśli chcemy full featured DDD, to core przedsięwzięcia polega na takiej pracy z biznesem, aby najpierw UL oraz spójny i powszechny model pojawił się w głowach biznesu i tam funkcjonował bez forkowania się.
2. O CORE DOMAIN
Mam nadzieję, że ten akapit się rozwinie, bo to imho absolutnie kluczowa rzecz. Wydaje mi się, że temat CD nie jest wystarczająco mocno podkreślany i w powszechnej świadomości niknie za Building Blockami.
Być może jest tak dlatego, że Core Domain ma trochę ulotną definicję i żeby ją namierzyć potrzeba sporo doświadczenia. Ja mam takie dwie historyjki o tym, czym jest CD:
1. No więc. Dawno dawno temu wymyślono maszynę do szycia. No i zaczęto się zastanawiać, jakby ją tu opatentować. Wiadomo, że pomysłowość ludzka nie zna granic i zawsze znajdzie się jakiś sposób obejście patentu. Szukano więc absolutnie kluczowej rzeczy, bez którego maszyna do szycia nie może istnieć. W końcu postanowiono opatentować...dziurkę w igle :) Genialny pomysł! Bez dziurki w igle ni cholery maszyny do szycia zbudować się nie da. A więc szukaj "dziurki w igle" w swoim biznesie i pamiętaj, że CD jest mniejsza niż Ci się wydaje.
2. A druga to taka meta-historia:) Co jest Core Domain w Domain Driven Design? Uwaga...Ubiquitous Language i wynikający z niego Bounded Context. Cała reszta już gdzieś była, ale bez UL i BC DDD to tylko zbiór best practices odnośnie architektury i designu. A więc core kilku tysięcy stron książek, artykułów i blogów o DDD, Evans ujął w kilku akapitach. UL i BC - to jest sedno. Reszta to przypisy :)
Mam parę ciekawych heurystyk nt. namierzania Core Domain. Jak łatwo się domyśleć z mojej perspektywy wszystko sprowadza się do zadawania pytań. Ale o tym to już w 4oczy :)
pozdr,
mb
Odnośnie "dzidy": takie przekaz był na slajdzie tytułowym:P
Natomiast treści prelekcji była bardziej subtelna: najpierw określasz klasę problemu, później zastanawiasz się nad klasą rozwiązania technicznego - a zwykle rozwiązanie techniczne nie jest tutaj problemem, a właśnie model problemu.
Co do destylacji Core Domain to najprostsza technika: biznes spisuje dokument wizji (połowa strony A4) - co jest wizją tego systemu, powodem jego tworzenia, co zarabia, co daje przewagę na konkurencja, gdzie mieszkają "sexi ficzers".
"Co do destylacji Core Domain to najprostsza technika: biznes spisuje dokument wizji (połowa strony A4) - co jest wizją tego systemu, powodem jego tworzenia, co zarabia, co daje przewagę na konkurencja, gdzie mieszkają "sexi ficzers"
Akurat! Chiałbym zobaczyć Twoją rozmowę z tym biznesem i analizę tego dokumentu. Bo z góry mogę powiedzieć, że guzik z tego będzie. A ograniczenie miejsca na pisaninę nie sprawi, że Core Domain wydestyluje się samo.
Ale ok pobawmy się. Na więc weźmy portal http://www.devcastzone.com , którego jestem współ{pomysłodawcą, właścicielem}, a więc jak by nie było biznesem. No więc jako biznes odpowiadam na Twoje pytanie:
Panie Sławku taka, skrócona wizja tego projektu brzmi następująco: Celem projektu jest stworzenie e-usługi szkoleniowej dostępnej dla każdej osoby, która zechce poszerzyć swoją wiedzę i umiejętności w zakresie wytwarzania oprogramowania. Stworzony portal dostępny będzie publicznie za pośrednictwem Internetu, każda chętna osoba będzie mogła się zalogować i za opłatą skorzystać z e-usługi.
Zatem nie będą narzucone żadne dodatkowe ograniczenia i projekt jest zgodny z polityką równych szans oraz nie prowadzi do dyskryminacji ze względu na płeć, rasę lub pochodzenie etniczne, religię, światopogląd, niepełnosprawność, wiek lub orientację seksualną.
Projekt ma duży pozytywny wpływ na środowisko, gdyż powoduje zmniejszenie ilości zużywanego papieru dzięki zastosowaniu elektronicznej formy informacji. Zakładając, że przeciętne materiały szkoleniowe mają objętość 100 stron i przyjmując (bardzo ostrożnie), że w miesiącu przeszkolonych zostanie 50 osób, to daje to 5000 stron (10 ryz papieru) miesięcznie=120 ryz papieru rocznie zużytego w tradycyjnych stacjonarnych szkoleniach. Projekt redukuje zużycie papieru do zera.
Projekt wspiera również zasadę zrównoważonego rozwoju, gdyż nie tylko nie umniejsza szans przyszłych pokoleń na zaspokojenie swych potrzeb, lecz przeciwnie - promując edukację daje szansę przyszłym pokoleniem na bardziej wydajne zaspokojenie potrzeb.
I wydedukuj z tego Core Domain :D A potem powiem Ci jaka jest, bo jej namierzenie zajęło nam o ile pamiętam z 4 całodniowe sesje brainstormingu.
Chyba Wam wystawię fakturę za product placement:P
Disclaimer: wchłaniasz materiały ze wspomnianego portalu na własne ryzyko;)
No ale żarty na bok...
Tak jak piszesz dostęp do "biznesu" na poziomie dotarcia do wizji może być problematyczny. Są organizacje gdzie jest to standard, są też takie gdzie jest to niemożliwe - np. z tej przyczyny, że IT ma właśnie nie rozumieć "master planu". Ok, to zrozumiałe, mamy zatem projekt typu hodowla pieczarek (pieczarki hoduje się w ciemni) i musimy zaakceptować ryzyko z tym związane...
Odnosząc się do poprzedniego komentarza jeszcze: zespoły nie posiadające ekspertów mogą wciąż odnosić znaczne korzyść ze stosowania technik DDD. Stosowanie tych technik "nie wybacza" nierozumienia i prowadzi do
zadawania pytań, którym zwykle nie zadajemy, co w efekcie poprawia jakość (precyzję) modelu.
Ale wracając do wizji.
Podałeś przykład. Gdybym dostał taki tekst, to bym zaczął próby dotarcia do prawdziwej wizji:
"Panie Michale, to co Pan przedstawia wygląda jak wstęp do jakiegoś wniosku o dofinansowanie (co wnioskuję po logotypach na makietach UI). Darujmy sobie bullshit i przejdźmy do sedna. Czy chcą Państwo np analizować/prowadzić ścieżki rozwoju kompetencji? Czy chcą Państwo oferować programy lojalnościowe? Czy chcą Państwo wyłaniać utalentowanych ludzi i sprzedawać ich poławiaczom niewolników? Domyślam się, że prosty CMS do wrzucania filmików plus standardowy moduł płatności to nie jest to o co tak naprawdę chodzi, przyczyna tworzenia tego projektu jest inna. Ale jeżeli chodzi jedynie o CMSa to radzę zlecić projekt dynamicznej firmie specjalizującej się w tego typu systemach i datować sobie modelowanie i tego typu zbędne rzeczy".
Nie wiem czy z przykładu klarownie wyłania się różnica pomiędzy dokumentem wizji a reklamą ficzerów, ale chodzi o to, że dążąc do powodu dla jakiego powstaje ten system możemy dojść do domen, które byłyby ukryte gdzieś w gąszczy ośmiotysięczników (np śledzenie userów, model ścieżki rozwoju, itd).
Generalnie racja. W tym przypadku, wg mojej oceny Core-Domain był...proces gwarantujący, że szkolenie będzie miało założoną jakość.
Mocno się zmóżdżaliśmy zanim wpadliśmy na to, że zarabiamy na kontencie, a nie na narzędziu (z małą gwiazdką w kierunku usability). Niby oczywista sprawa, ale jak zaczynasz rozkminiać od początku co z czym się je, to wszystko zaczyna się plątać.
W tym przypadku Core Domain nie było czyś "programistycznym" ale leżącym poza IT. Tym więc zajęliśmy się osobiście, resztę zdelegowaliśmy i jak się okazało była to dobra decyzja zwłaszcza finansowo. Gdybym robił to jeszcze raz to jasne, że pewne rzeczy zrobiłbym inaczej, ale generalnie było ok. (np. gdy pisaliśmy wniosek nie było portali tego typu, teraz jest już sporo i widzę, że CD powinno mocniej uwzględniać sposób w jaki user jest prowadzony przez szkolenie).
Nie wiem, czy takie myślenie o Core Domain jest zgodne z wykładnią DDD, bo w literaturze nie znalazłem takiego stwierdzenia wprost. Wydedukowałem to sobie i moim zdaniem trzyma się kupy:)
W książkach Evansa i Vernona tego nie ma, ale w materiałach video Evansa, Younga i Dahana jest podejście od tej strony.
Tak na prawdę agilowe modelowanie DDD zaczyna wówczas poszerzać zakres z analizy systemowej wchodząc na poziom analizy biznesowej.
@Sławek
i mówił też o tym Michał Bartyzel na tegorocznej Confiturze :)
A nie wiem, nie byłem:P
Prześlij komentarz