!FrAgile Thinking

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.