Archive for Listopad, 2008
Ubiquitous Language – wszechobecnym językiem w koncepcji Domain Driven Design
W poprzednim poście omówiłem znaczenie języka zwanego „ubiquitous language” w koncepcji Domain Driven Design(DDD) oraz modelu obiektowego zawartego w kodzie aplikacji, przedstawiającego domenę biznesową realizowanego projektu. Jak już wspominałem, wymiana informacji pomiędzy ekspertem biznesowym a zespołem realizującym projekt jest definiowana przy użyciu „ubiquitous language”, który staje sie kanałem komunikacji pomiędzy światem biznesu i IT. Dodatkowo należy zwrócić uwagę, że zgodnie z zaleceniami DDD, język ten powinien być również stosowany w zespole IT realizującym projekt jako sposób komunikacji. Podejście to eliminuje wszelką niepotrzebną translację informacji związanych z wymaganiami.
W celu lepszego zrozumienia tworzenia i zastosowania „ubiquitous language” przedstawiony zostanie przykład rozmowy pomiędzy ekspertem domeny biznesowej a programistami. Rozmowa ta dotyczy domeny związanej z aukcjami internetowymi. Ponieważ, większość użytkowników internetu zapoznana jest z licznymi systemami aukcji internetowych zakładam, że przykład będzie prosty i zrozumiały.
W takim razie zaczynamy i dołączamy się do trwającej już konwersacji:
Ekspert: (kończy zdanie)
Programista1: Z tego co zrozumiałem, to każdy użytkownik systemu będzie miał możliwość uczestniczenia w wystawionej licytacji.
Ekspert: Nie do końca, dlatego, że licytacja jest inicjowana przez użytkownika, który również może brać udział w innych licytacjach, ale nie we własnej.
Programista1: Okay, w takim razie każda aukcja ma swojego właściciela, będącego użytkownikiem systemu.
Ekspert: Dokładnie. Jeżeli chodzi o sam przebieg licytacji, to użytkownik musi podać przy podbijaniu oferowaną przez siebie kwotę, którą jest w stanie zapłacić. Kwota ta musi być wyższa od dotychczas najwyższego podbicia. W innym przypadku jego oferta nie zostanie przyjęta.
Programista2: Czyli każda licytacja posiada wiele podbić dokonanych przez różnych użytkowników, z których wygra to, które jest najwyższe.
Ekspert: Tak
Programista2: Nasuwają mi się jednak dwa pytania: Kiedy zakończy się licytacja? Czy jako użytkownik, który ostatnio podbił cenę licytacji mogę nadal podbijać oferowaną przeze mnie kwotę?
Ekspert: Bardzo dobre pytania. Użytkownik wystawiając przedmiot musi wybrać czas trwania licytacji. Zakładamy, że będą tylko dwie możliwości dotyczące tego okresu – jeden lub dwa tygodnie.
Programista2: Aha.
Ekspert: Odnośnie drugiego pytania. Hmm… Nie. Użytkownik nie powinien mieć możliwości podbijania licytacji, którą jako ostatni podbił. Informacje o licytacji dostępne dla każdego użytkownika powinny zawierać tytuł, opis i aktualną cenę licytacji. Poza tym wymagane jest wyświetlenie szczegółowych informacji o każdym następnym podbiciu, którego dokonano w danej licytacji. Informacjami tymi są kwota podbicia, nazwa użytkownika, który podbijał i czas informujący o tym, kiedy do podbicia doszło. To rozwiązanie zapewni, że użytkownik będzie widział również historię swoich własnych podbić oraz, że nie będzie starał się niepotrzebnie podbijać daną licytację. W przypadku, gdy jednak spróbuje podbić swoje ostatnie podbicie to powinniśmy go poinformować o tym, że jest to niemożliwe.
Programista1: Ok. Rozumiem, że aktualna cena licytacji, to kwota ostatniego podbicia?
Ekspert: Tak, dokładnie.
Konwersacja ta przedstawia jak w prosty sposób może dojść do wymiany wiedzy dotyczącej domeny biznesowej pomiędzy ekspertem a programistą. Oczywiste jest to, że początkowy obraz omawianej części domeny nie jest całkowicie przejrzysty, ale pozwala on na jej podstawowe zrozumienie. Wymagane jest, by osoby realizujące projekt zrozumiały jak najwięcej na temat domeny. Dlatego też zadawane przez nich pytania w trakcie każdej konwersacji z ekspertem pozwalają na poszerzenie ich wiedzy i wyeliminowanie wszelkich nieporozumień. Pytania te również pozwolą w wielu przypadkach wskazać na nieścisłości w przedstawianych przez eksperta domenowego informacjach. Przykładem jest jedno z pytań zadanych w powyższej konwersacji dotyczące podbijania przez użytkownika własnej oferty.
Informacje pojawiające się w trakcie konwersacji są ulotne, w związku z tym należy w odpowiedni sposób uchwycić je tak, by były dostępne dla każdego w późniejszej fazie projektu. Jednym z rozwiązań jest spisanie tych informacji. Rozwiązanie to prowadzi do tworzenia obszernych dokumentów, które w z czasem stają się nieprzejrzyste i najczęściej niezsynchronizowane z bieżącą postacią domeny biznesowej. Poza tym udowodnione jest, że ludzki mózg jest w stanie w najszybszy sposób pojąć elementy wizualne, dlatego jednym z najlepszych rozwiązań jest tworzenie w trakcie konwersacji diagramów przedstawiających koncepcje występujące w domenie.
Diagramy te najlepiej powinny być przedstawione tak by były zrozumiałe zarówno dla ekspertów domenowych jak i programistów. Dlatego, że diagramy te są częścią konwersacji i każde pojawiające się nowe aspekty lub modyfikacje powinny być natychmiastowo w nich odzwierciedlone. Nasuwa się pytanie, jakiego rodzaju diagramów używać? To zależy. Można oczywiście stworzyć na własne potrzeby standard diagramów, który nie będzie wymagał wielkiego nakładu pracy by się z nim zapoznać i go używać. Jako, że my programiści, na codzień mamy do czynienia z językiem UML, kolejnym rozwiązaniem może być wykorzystanie dostępnych w tym standardzie diagramów.
Najczęściej wykorzystywany do tych potrzeb jest zminimalizowany diagram klas, który znany jest również jako Domain Model opisany przez Craiga Larmana w książce Applying UML and Patterns(3rd edition). Warto zauważyć, że nazwa tego rodzaju diagramów jest zbieżna z nazwą wzorca Domain Model, który definiuje zasady tworzenia modelu obiektowego, zawartego w kodzie będącego jednocześnie jądrem realizowanego projektu. Pomiędzy diagramem Domain Model a modelem obiektowym występuje bardzo bliska relacja. Ponieważ model obiektowy występujący w kodzie aplikacji powinien w pełni odzwierciadlać najbardziej aktualny diagram zamodelowany w oparciu o język „ubiquitous language”.
Komponenty służące do przedstawienia domeny biznesowej
Modelowanie diagramów domeny w oparciu o wyżej wspominany rodzaj diagramu klas, wymaga najczęściej nabycia wiedzy i oswojenia się z zagadnieniem ze strony eksperta domenowego. W artykule Domain-Driven Design in an Evolving Architecture, można znaleźć cenne informacje na temat wykorzystania tego rodzaju diagramów jak i koncepcji DDD do modelowania modelu domeny. Przykład zawarty w artykule jest oparty o projekt, który był realizowany przez jedną z największych gazet w Anglii – Guardian.
Powróćmy do przedstawionego przykładu: w trakcie konwersacji pojawiło się wiele informacji dotyczących elementów występujących w domenie aukcji internetowych związanych z ich właściwościami oraz zachowaniem. Wymagane jest, aby diagram klas modelu domeny nie zawierał metod, których celem jest przedstawienie zachowania. Należy modelować w trakcie konwersacji tylko obiekty, ich właściwości oraz relacje występujące między obiektami. Widoczny jest tutaj wspominany w poprzednim wpisie podział elementów pojawiających się w „ubiquitous language” na rzeczowniki (obiekty i ich właściwości) i czasowniki (metody obiektów). Gdzie diagram tylko przedstawia występujące rzeczowniki.
Najczęściej powtarzającym się hasłem w konwersacji jest licytacja, która jest słowem kluczem, dlatego, że definiuje ono główny obiekt w domenie aukcji internetowych. Każda licytacja powinna być podbijana przez różnych użytkowników. W związku z tym, że podbicie wiąże się z operacją, która wnosi do systemu istotne informacji, zostaje ono również w konwersacji traktowane jako obiekt domenowy, posiadające określone właściwości. Ostatnim i bardzo ważnym obiektem jest użytkownik, który pełni w opisanym scenariuszu dwie role. Jest osobą, która wystawiła aukcję, oraz osobą biorącą udział w aukcji jako osoba licytująca. Poniższy diagram przedstawia wyznaczone w trakcie konwersacji obiekty, które zostały określone i potwierdzone przez eksperta domenowego.
Diagram przykładowego modelu domeny związanez z aukcjami internetowymi
Posiadając ściśle określone wymagania wyrażone w postaci „ubiquitous language” i diagramu przedstawiające obiekty występujące w analizowanej domenie, możemy przejść do implementacji modelu obiektowego przedstawionego w postaci kodu. Ze względu na długość tego postu część ta zostanie opisana w kolejnym poście.
1 comment Listopad 24, 2008
Wstęp do Domain Driven Design
Pierwszy wpis techniczny – długo zastanawiałem się nad tym, czego powinien on dotyczyć? Kiedy w zasadzie powinien się tutaj pojawić? W momencie zdobycia rzetelnej wiedzy na dany temat, poznania potrzeb i wymagań szanownych odbiorców, czy może w piękny jesienny dzień (niczym spadający liść, który zapowiada nadchodzącą zimę, a więc proces-cykl). Jedyne, czego byłem pewny to to, że nie będzie to wpis dotyczący jednowątkowego tematu. Początkowo myślałem, że warto by było omówić szeroki temat dotyczących maperów obiektowo relacyjnych, koncentrując się na NHiernate i Linq To Sql. Tak jednak się nie stało (mimo to zapewniam, że prędzej czy później tego rodzaju wpisy się pokażą), uznałem, że jest to zbyt techniczny/skomplikowany temat na sam początek (a przecież nie chciałbym nikogo zniechęcić).
Ostatecznie zdecydowałem się omówić temat „Domain Driven Design”. DDD jest według mnie, a także według cenionych przeze mnie autorytetów, jedną z najciekawszych koncepcji wytwarzania oprogramowania. Dodatkowym bodźcem, który skłonił mnie do opisania DDD była lektura książki Erica Evansa „Domain Driven Design – tackling complexity in the hart of software”.
Zaczynamy.
Czym jest Domain Driven Design(DDD)?
Nie jest to łatwa odpowiedź, dlatego, że nie jest możliwe w dwóch czy trzech zdaniach opisać najważniejsze cechy tej koncepcji. Wydaje mi się, że najłatwiej można by ująć, że DDD to koncepcja pozwalająca na realizację projektów IT zapobiegająca tworzeniu się przepaści pomiędzy osobami znającymi biznes(klient, analityk) a zespołem tworzącym dany projekt. Zapewne sobie myślicie, co w tym takiego wielce rewolucyjnego, w końcu każdy projekt wymaga pewnej współpracy pomiędzy biznesem, dla którego realizowany jest projekt a działem IT, który go realizuje. Pytanie, które powstaje – co to znaczy „pewna współpraca”? Chyba każdy już zna poniżej przedstawiony rysunek.
Źródła: http://maluga.com.pl/wp-content/uploads/etapy-budowy-systemu.jpg
Rysunek ten moim zdaniem przedstawia właśnie efekt tej „pewnej współpracy”, w której często sam brałem udział i zapewne jeszcze nieraz będę 
Można by pomyśleć, że przyczyny efektu końcowego przedstawionego na rysunku są związane ze źle zebranymi wymaganiami lub ze złą formą przekazania ich programistom. Owszem, często się tak dzieje, że specyfikacja jest niezrozumiała, mało przejrzysta czy zawiła, co w znacznej mierze wpływa na niepowodzenie projektów informatycznych. Nawet w najbardziej optymalnej sytuacji sama specyfikacja nigdy nie wystarczy, by zbudować w pełni odpowiadający klientowi system informatyczny. W większości przypadków specyfikacja zostaje interpretowana na wiele sposobów i w efekcie końcowym oprogramowanie nie staje się rzeczywistym odzwierciedleniem domeny biznesowej.
Dzieje się przede wszystkim tak, dlatego, że w projektach tego typu nie występuje jawna komunikacja pomiędzy osobami znającymi daną domenę biznesową a zespołami wytwarzającymi oprogramowanie. Dlatego też model stworzony przez programistów odbiega od pożądanej postaci. Jednym z głównych powodów, który decyduje o braku wcześniej wspomnianej współpracy, jest różnica żargonów, pomiędzy tymi stosowanymi w danej domenie biznesowej a tymi używanym przez programistów. W dzisiejszych czasach większość projektów informatycznych jest realizować koncentrując się przede wszystkim na danych i relacjach występujących pomiędzy tymi danymi. Prowadzi to do tego, że w rozmowach pomiędzy programistami pojawiają się sformułowania typu „do tabeli zamówienia powinna zostać dodany nowy rekord w przypadku, gdy…”. Te słowa dla osoby z biznesu są całkowicie nie zrozumiałe, dlatego, że nie zna ona się na bazach danych – i dobrze, bo bylibyśmy bezrobotni.
Panaceum na tego typu bolączki jest wprowadzenie spójnego wszechobecnego języka, tzw. ”ubiquitous language”. Ubiquitous language jest jednym z najważniejszych elementów Domain Driven Design, dlatego, że zapewnia on spójną komunikację pomiędzy dwoma światami – biznesu i programistów. Język ten należy kształtować od samego początku projektu, rozwijając go przede wszystkim w trakcie konwersacji, w ramach, których zostają omawiane wymagania biznesowe. Konwersacje te, służące przekazaniu i rozpoznaniu potrzeb klienta, są jednym z głównych elementów metodologii zarządzania projektów zwanymi metodologiami zwinnymi (Agile). Dlatego też, jednym z podstawowych wymagań zastosowania DDD jest sposób prowadzenia projektów przy użyciu metodologii zwinnych.
Samo zdefiniowanie wspólnego języka pomiędzy klientem a zespołem, nie zapewnia sukcesu. Dopiero zaimplementowanie systemu informatycznego w sposób taki by odzwierciadlał występujące w języku „ubiquitous language” elementów zapewni ścieżkę do sukcesu. Implementacja ta jest dokonywana przy pomocy modelu obiektowego znanego, jako wzorzec Domain Model pozwalającego na abstrakcję modelu biznesowego wyrażonego w postaci kodu. Więcej informacji na temat architektury aplikacji, w której skład wchodzi Domain Model można znaleźć tutaj. Dodatkowo zapewniam, że przyszłe wpisy będą koncentrowały się na implementacji tego wzorca, jako że przedstawia on serce aplikacji opartej o DDD.
Jednym z najważniejszych wymogów DDD względem implementacji modelu obiektowego przedstawiającego domenę biznesową jest to by obiekty zawarte w tym modelu nie przedstawiały tylko i wyłącznie rzeczowniki pojawiające się w „ubiquitous language”, ale również czasowniki. W końcu to czasowniki przedstawiają zachowanie, którym cechuje się logika każdego systemu informatycznego. To stwierdzeni może się wydawać błahe i oczywiste, ale w większości systemów zapomina się o tym stosując modele obiektowe oparte o klasy biznesowe posiadające tylko i wyłącznie pola będące rzeczownikami. Model składający się z klas bez metod przedstawiających czasowniki został zdefiniowany, jako anty wzorzec znany szerzej, jako Anemic Domain Model. Najczęstszym powodem występowania tego wzorca jest definicja modelu obiektowego przy użyciu a wręcz mapowaniu wcześniej stworzonego schematu relacyjnej bazy danych będącego jedynie odzwierciedleniem stanu obiektów.
W kolejnym wpisie postaram się przedstawić przykład konwersacji pomiędzy ekspertem domeny biznesowej a programistą. Ta konwersacja na celu będzie miała ukazać przykład tworzenia się jezyka „ubiquitous language”, współdzielonego pomiędzy nimi. Następnie na podstawie elementów zawartych w tym języku wyznaczony zostanie przykładowy model obiektowy wraz z jego implementacją.
2 comments Listopad 17, 2008
Container.AddComponent( typeof(FrAgileThinkingBlog)) – czyli developerskie powitanie ;)
Witam!
I znowu przyszła jesień… Dni stają się coraz krótsze, chłodniejsze… i cóż innego można robić w mokre, szare, ponure wieczory jak nie pisać bloga?
A tak naprawdę powodów do pisania bloga jest znacznie więcej. Od dłuższego czasu planowałem podzielić się z innymi moją wiedzą. Na ile informacje zawarte w tym blogu okażą się dla Was przydatne, ocenicie sami.
Blog ten będzie poświęcony przede wszystkim mojej pracy i hobby, czyli wytwarzaniu oprogramowania opierającego się przede wszystkim na metodologiach zwinnych tak zwanych “Agile”. Stąd też nazwa mojego bloga – !FrAgile thinking. Jako, że na co dzień jestem programistą Microsoft .NET, będę się skupiał na wykorzystaniu metodologi Agile w tym środowisku. Poza aspektami czysto programistycznymi tej metodologii postaram się wypowiadać również na temat elementów stricte związanych z zarządzaniem projektami.
Technologie informatyczne to nie jedyne moje hobby, dlatego spodziewajcie się nie jednej pochwały lub krytycznej oceny pieśni ludowych:) wchodzących w skład gatunku muzycznego electro, minimal i deep house.
1 comment Listopad 16, 2008
