Po 6 latach praktykowania DDD, prowadzenia i uczestniczenia w licznych warsztatach i szkoleniach chyba wreszcie zrozumiałem o co chodzi w całym tym Domain Driven Design...
Wszystko dzięki trafiającemu (jak zwykle) w sedno postowi Jarka Żelińskiego: Czy aby na pewno zarządzamy procesami biznesowymi?
Wstęp
Patrząc na warstwową architekturę systemu opartego na DDD mamy:UI
----------------------
Application (API)
----------------------
Domain Model
----------------------
Infrastructure
(możemy użyć również popularnej ostatnio metafory Heksagonu - ale nie wpływa to na wywód)
W warstwach UI+APPlication możemy możemy mieć zamodelowany proces biznesowy. Ew. szczególnym klientem do API (również obok np apliakcji webowej) może być silnik procesów biznesowych.
W warstwie Domain rezyduje model bazowych reguł biznesu ("fizyki" biznesu) zamodelowany przy pomocy Building Blocks DDD, które chronią niezmienniki. Więcej o BB: DDD krok po kroku.
Problem: Od czego zacząć modelowanie?
Od procesu czy od domeny? Innymi słowy: od ogółu czy od szczegółu?W Domain Driven Design zaczynamy (niespodzianka) od modelowania warstwy Domain. API i proces to rzecz wtórna.
To zależy...
Jak w każdym nietrywialnym przypadku, odpowiedź na pytanie zależy od kontekstu.
W przytoczonym na wstępie artykule znajdziemy olśniewającą (przynajmniej dla mnie) wskazówkę:
- czy proces biznesowy wyłania się z reguł niższego rzędu - innymi słowy model domenowy nakłada ograniczania, które wyznaczają "trajektorię" procesu, który lawiruje pomiędzy nimi niczym strumień rzeki w jej korycie (posługując się metaforą Jarka)
- czy może to raczej proces narzuca kształt modelowi domenowemu?
W DDD podchodzimy do modelu w ten pierwszy sposób - zaczynamy od domeny, czyli fundamentalnych reguł i ograniczeń, w które wpasowuje się proces.
Trudne pytanie
Po czym poznać z którą sytuacją masz do czynienia? Najpewniej w dużym systemie mamy obie...
//===============================
To w sumie wydaje się oczywiste, ale sztuką jest tak ubrać myśl w słowa, aby (np przez porównanie dwóch podejść) ująć ideę w jednoznaczny sposób.
9 komentarzy:
:)
spotykam się czasami z opinią, że "niektórzy konsultanci" od modelowania procesów niczego nie modelują ale "kręcą film" chodząc po firmie. Innymi słowy nie mając pojęcia "dlaczego akurat tak" zapisują jakiś zaistniały scenariusz.
Tak na prawdę ludzi ograniczają w ich działaniach wewnętrzne regulaminy oraz posiadane umiejętności. Proces jaki zajdzie jest skutkiem. Owszem Warto go "modelować" by takie skutki oceniać i ewentualnie "uszczelniać" ale nie jest to żaden "mechanizm funkcjonowania".
Jak na tym tle wygląda User Story z ust usera? Tak samo jak proces: to postrzegany skutek a nie przyczyna.
Od pewnego czasu, gdy chce zrozumieć (analiza i model) organizację, robię jej model obiektowy (procesowy też ale później, służy do testowanie modelu obiektowego). I tu właśnie pokazuje się potęga DDD: dziedzina systemu to nic innego jak fragment (zakres projektu) modelu danej organizacji. Mając model obiektowy, na bazie wzorców DDD, danej firmy oraz mając (najważniejszy!) model przypadków użycia robimy selekcję: które elementy modelu dziedziny będą realizowane przez system a które pozostaną poza nim. Ale całość MUSI nadal "trzymać się kupy". Wtedy np. FabrykaFaktur wejdzie w zakres projektu (system ma wystwiać faktury) ale np. Usługa "wylicz podatek VAT" pozostanie poza zakresem (zostaje przyporządkowana do aktora, to nadal jego wymagana umiejętność i wiedza). Owszem to prosty system ale jednak.
Dlatego DDD (nie raz stosuję prostszy model BCE, bo niewprawny biznes łatwiej go przyjmuje ;)) to kluczowe narzędzie na etapie analizy problemu i określania zakresu projektu. Ten model powinien 1:1 wejść do implementacji jako Domain Model.
Czy jest możliwy proces biznesowy trudny do wykonania przy użyciu modelu? Zapewne tak. W takim przypadku, czy nasz model ("odkryty" inside-out), wiernie oddaje rzeczywistość przedsiębiorstwa? Raczej nie. Innymi słowy, czy nasza domena po prostu istnieje i potem "upychamy" ja w procesy, czy tez procesy (lub tez przypadku użycia) kształtują nasz model?
Moim skromnym osobistym zdaniem model wynika z przypadków użycia, odkrywany od zewnątrz. Nie będzie on starać się wspierać hipotetycznych przypadków lub tych "na zaś". Będzie on odwzorowywać dokładnie to, co jest od systemu wymagane (i te problemy które system ma rozwiązać)
Nie wydaje mi się, aby DDD narzucała nam metodologię odkrywania modelu. Można dokonywać tego od zewnątrz lub od wewnątrz. Wybór należy do ciebie :)
"Moim skromnym osobistym zdaniem model wynika z przypadków użycia"
moim zdaniem nie, przypadki użycia nie kształtują narzędzi, se "tylko tym co można z ich pomocą zrobić".
Metafora z bilardem Fowlera to doskonale pokazuje: kule przemieszczają się zgodnie z prawami fizyki a nie na żądanie gracza.
Przypadki użycia to etap analizy i projektowania, to życzenia usera, powszechne nazywanie ich "pobożnymi życzeniami" nie jest przypadkiem. Jeżeli user poprzestanie na opisie swojego celu to jeszcze ok, ale już "user story" z ust usera to nie raz "bilard w stanie nieważkości".
Po drugie przypadki użycia nie zawierają żadnej informacji o "algorytmach" więc jakim cudem mają posłużyć do modelowani dziedziny? Moim zdaniem najpierw muszę zrozumieć czym jest stół bilardowy i kule, by mieć podstawy do projektowania "scenariuszy" i przy okazji weryfikowania ich realizowalności.
Jeżeli model dziedzinowy jest poprawny, to każdy model realnego procesu jest łatwy do zamodelowania i sprawdzenia.
@Marcin
Jarek już odpowiedział. W sumie nic nowego nie dodam, jedynie powtórzę to samo swoimi słowami:
W jakim celu organizacje standaryzują procesy? Odnosząc się do modelu kompetencji http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition niedoświadczeni pracownicy potrzebują procesów. Jeżeli organizacja ma dużą rotację pracowników to tym bardziej. Natomiast eksperci wiedzą "o co tak na prawdę chodzi w głębokich regułach" a proces, to jedynie jakaś "projekcja" ich wiedzy na potrzeby początkujących.
"Czy jest możliwy proces biznesowy trudny do wykonania przy użyciu modelu?"
W takim razie coś nie nie tak z modelem - nie odpowiada rzeczywistości biznesu. Albo procesem - ktoś "majstruje w matrixie";)
Wydaje się, że z Twojej wypowiedzi wynika, że model jest rozumiany jako struktury danych wspierające proces. Może tak być, ale to już nie będzie model w sensie DDD.
"Nie wydaje mi się, aby DDD narzucała nam metodologię odkrywania modelu. Można dokonywać tego od zewnątrz lub od wewnątrz."
Jeżeli DDD tratować jedynie jako zestaw Building Blocks (i najlepszych praktyk ich tworzenia) to tak. Ale jeżeli przyjrzeć się oficjalnemu procesowi Modeling Whirlpool http://domainlanguage.com/ddd/whirlpool/ i dosłownie potraktować nazwę Domain DRIVEN to zaczynamy od domeny.
Ale to wszystko oczywiście na pierwszych 2 poziomach Dreyfus, gdzie szukamy mechanicznej procedury postępowania. Natomiast mózg biegłego modelarza pewnie robi obie rzeczy (proces, domena) równolegle.
inżynieria oprogramowania to filozofia xxi wieku...
heh coś w tym jest:P
bo w sumie próbujemy zamodelować rzeczywistość...
ale podchodząc filozoficznie: być może nie ma czegoś takiego jak rzeczywistość, jest tylko narracja sprawozdawców...
niektórzy mając mindest procesowy, guiowy, czy domenowy będą nam o niej opowiadać w specyficzny sposób ze specyficznymi zniekształceniami...
Cisza, cisza, cisza. Czekam na wpis:)
Chodzi mi po głowie seria poświęcona specjalnym hakom w DDD, w tym właśnie o stosowalności. Jest to bardzo dużo, ale prowadząc po 2 szkolenia w tygodniu (z czego większość na temat DDD lub zbliżone) po prostu nie mam siły aby zebrać myśli wieczorem... ale może w lutym...:)
Jeżeli chodzi o samo zarządzanie procesami biznesowymi, to warto jest je poddać szczegółowej analizie, podczas której identyfikowane są wszystkie nieefektywności i obszary wymagające poprawy. Właściciele firm często korzystają w tym celu z specjalistycznych usług konsultingowych - https://www.crowe.com/pl/services/konsulting/zarzadzanie-procesami, które służą głównie wskazaniu efektywnych oraz optymalnych rozwiązań w oparciu o oszczędności kosztowe przedsiębiorstwa.
Prześlij komentarz