Ograniczony kontekst

Jedną z najważniejszych koncepcji Domain Driven Design jest ograniczony kontekst (ang. bounded context). Postanowiłem o niej napisać z kilku powodów. Po pierwsze nie widziałem żeby ktoś ją świadomie stosował. Po drugie wydaje mi się ciekawa. Po trzecie, gdy komuś o niej opowiadam, to widzę coś na kształt "wielkich oczu", zdziwienia.

Starożytna, chińska mapa świata, Chiny w centrum świata, reszta państw dookoła	Współczesna mapa polityczna

Powyższe rysunki obrazują dwa różne modele tej samej, niezwykle skomplikowanej dziedziny, z którą związane są rozmaite problemy. Tą dziedziną jest oczywiście świat, w którym żyjemy ;). Zatem który model jest lepszy ? Ten po lewej, czy ten po prawej ? Niestety nie ma poprawnej odpowiedzi na tak postawione pytanie. Przed udzieleniem odpowiedzi należałoby bowiem wyjaśnić: "lepszy do czego" lub raczej "bardziej użyteczny do czego".

Model po lewej, na którym Chiny są w centrum świata, doskonale rozwiązuje problem informowania odbiorcy o tym, że Chiny są najważniejszym państwem na świecie, a na inne państwa nie warto zwracać uwagi. Natomiast nie bardzo nadaje się do nauczania geografii w gimnazjum ;). Model po prawej pokazuje jakie są państwa, ich granice i ich położenie na kontynentach we współczesnym świecie. Dzieci w gimnazjum mogłyby więc z powodzeniem korzystać zeń na lekcjach geografii, w przeciwieństwie do starożytnych Chińczyków, którzy gotowi pomyśleć, że najważniejszym państwem na świecie jest Rosja ;).

Czy istnieje model, który rozwiązuje wszystkie problemy, które mogą się pojawić w jego dziedzinie ? Odpowiedź brzmi nie, powyżej pewnego poziomu złożoności. Gdybyśmy spróbowali stworzyć mapę, która zawiera wszystkie państwa, wszystkie rzeki, jeziora, miasta, drogi, bogactwa naturalne, a do tego informuje, że Chiny są najważniejszym państwem na świecie, to zapewne efekt naszej pracy byłby zupełnie nieczytelny. Zamiast rozwiązywać te wszystkie problemy, nie rozwiązywałby żadnego.

Czas najwyższy na morał tej opowiastki. Analogiczne zjawisko zachodzi w świecie oprogramowania biznesowego. Gdy mamy bardzo skomplikowaną dziedzinę biznesową i duży zespół programistów (np. 20 osób), i próbujemy zbudować aplikację w oparciu o jeden model, to prawdopodobieństwo porażki tego przedsięwzięcia jest bardzo wysokie. Przez porażkę rozumiem tutaj niekoniecznie niemożność wydania działającej aplikacji. Porażką może być nieczytelny kod, nieoptymalne działanie, przekroczony budżet, dużo błędów, narastające trudności przy wypuszczaniu nowych wersji, programiści uciekający z projektu ;), itd.

Jeden model w skomplikowanych projektach nie zadziała zasadniczo z dwóch powodów. Po pierwsze, tak jak w przypadku map, trudno efektywnie rozwiązywać dwa koncepcyjnie oddalone problemy biznesowe przy użyciu tylko jednego modelu. Przez "efektywne rozwiązanie" rozumiem poprawną, przejrzystą, łatwą w rozbudowie implementację. Problem narasta gdy mamy całą masę takich problemów każdy jakby "z innej beczki". Po drugie ciężko 20 programistom implementować jednocześnie jeden model - jest prawie pewne, że prędzej czy później jeden drugiemu namiesza, nie zrozumie intencji drugiego. Podsumowując: jeden model dziedziny o dużej złożoności prowadzi do syfu w kodzie ;).

Koncepcja ograniczonego kontekstu ma na celu pomóc nam uporać się z tym problemem. Jest tym samym jednym z ważniejszych pomysłów DDD na walkę ze złożonością w sercu oprogramowania. Zakłada ona jasne zdefiniowanie granic koncepcyjnie oddalonych od siebie problemów biznesowych. Dla każdego takiego ograniczonego zbioru (kontekstu) tworzymy osobny model i osobny wszechobecny język (ang. ubiquitous language). W każdym kontekście pracuje ograniczona ilość programistów, tak aby nie zakłócali sobie pracy. Nic nie stoi na przeszkodzie, a nawet jest wskazane, aby programistów "przełączać" pomiędzy kontekstami - jak powiedział Martin Fowler, high cohesion i low coupling dotyczą klas, a nie programistów ;).

Prawie na pewno wystąpi konieczność powiązania kontekstów. Rozwiązanie problemu w jednym kontekście może najpierw wymagać pracy innego kontekstu. Z tego powodu definiuje się tak zwaną mapę kontekstów (ang. context map), czyli zbiór reguł, które pozwalają "tłumaczyć" byty żyjące w jednym kontekście na byty w drugim.

Myślę, że czas na bardziej softwarowy przykład, który notabene pochodzi od Evansa. Dziedziną jest biznes transportowy, który zarabia na przewozie kontenerów pomiędzy różnymi miastami na świecie - jak na obrazku powyżej. Transport odbywa się drogą morską lub lądową, co wiąże się z szeregiem załadunków, rozładunków kontenerów w różnych portach, stacjach kolejowych itp. Kluczowym problemem w takiej dziedzinie jest śledzenie historii transportu towaru. Zadanie to doskonale rozwiązuje model przedstawiony na diagramie poniżej.

Mamy tutaj ładunek (ang. cargo), który posiada specyfikację swojej drogi (ang. route specification) od miejsca pochodzenia do celu transportu. Ładunek posiada również rozkład (ang. itinerary), czyli listę gałęzi (ang. leg). Gałąź to nic innego jak fragment drogi ładunku, np. podróż morska z Hong Kongu do Los Angeles lub podróż pociągiem z Los Angeles do Dallas. Gałąź posiada więc miejsce załadunku i rozładunku towaru. Miejsce załadunku pierwszej gałęzi rozkładu musi być równe miejscu pochodzenia towaru (ang. origin), a miejsce rozładunku ostatniej gałęzi musi być równe miejscu przeznaczenia (ang. destination) - wtedy mówimy, że rozkład spełnia specyfikację drogi. Żeby lepiej zobrazować czym są te gałęzie zamieszczam poniższy rysunek.



Przedstawiony model pozwala pracować z planem transportu towaru. Może np. posłużyć w aplikacji wystawiającej zlecenia przewoźnikom na poszczególnych gałęziach. W tej dziedzinie występują jednak inne problemy. Wyobraźmy sobie, że oprócz śledzenia transportu nasza aplikacja musi określić optymalną drogę (np. najkrótszą albo najtańszą albo najszybszą) z miasta, w którym klient nadaje przesyłkę do miasta docelowego. Tego typu zadanie można rozwiązać stosując teorię grafów (problem najkrótszej drogi). Powstaje pytanie czy powinniśmy do naszego modelu wprowadzać klasy, atrybuty, metody realizujące algorytmy teoriografowe ? DDD i koncepcja ograniczonego kontekstu mówią nie ! Powinniśmy raczej skorzystać z drugiego modelu, w którym będą klasy Graph, Vertex, Edge, Path i być może inne byty, o których można poczytać w książce do teorii grafów. Na tym przykładzie oczywiste staje się pojęcie mapy kontekstów. Musimy jakoś "przetłumaczyć" wynik działania algorytmu wyszukiwania najkrótszej drogi (zapewne obiekt klasy Path) na obiekt rozkładu (klasa Itinerary). Mapa kontekstów będzie w tym konkretnym przykładzie zawierać regułę, np. że atrybut name klasy Vertex odpowiada kodowi miasta, w którym następuje rozładunek/załadunek.

W przedstawionym przykładzie granice pomiędzy dwoma kontekstami są dobrze widoczne, wręcz jaskrawe. Prawdziwe scenariusze pisze jednak życie - wydzielanie kontekstów nie jest oczywiste, bo ich granice często są niewyraźne. Rozwinięcie koncepcji, które tutaj naszkicowałem znajdziecie w książce Evansa - zachęcam do lektury.

Naked Objects

Ostatnio moje zainteresowania programistyczne mocno oscylują wokół tematyki Domain Driven Design i przy okazji, jako że jest to temat dosyć pokrewny, natrafiłem na wzorzec zwany Naked Objects. W tym wpisie chcę przybliżyć główne założenia tego zagadnienia.

Wzorzec ten został opisany przez niejakiego Richarda Pawsona, który sporządził na ten temat swoją rozprawę doktorską. Postanowiłem więc sięgnąć do źródeł. Jak na każdą pracę doktorską przystało, również i ta Pawsona, stawia pewien problem, stara się odnaleźć jego genezę, proponuje rozwiązanie i rozprawia nad jego zaletami/wadami. W tym przypadku problemem jest niesławny anemiczny model - antywzorzec, który objawia się obiektami biznesowymi pozbawionymi odpowiedzialności rozsianej po procedurach. Pawson zauważa popularność tego antywzorca w aplikacjach enterprise dopatrując się takiego stanu rzeczy w niekontrolowanej ewolucji wzorca MVC. Można się zgodzić z taką genezą lub nie, ale fakt jest faktem, że problem istnieje. Proponowanym lekarstwem są właśnie Naked Objects.

Aby zrozumieć o co chodzi rozważmy poniższy rysunek:


Przedstawia on 4-warstwową architekturę aplikacji znaną chociażby z DDD, czy z UP, której sercem jest warstwa obiektów biznesowych (Domain object) odpowiadjących bytom, że świata rzeczywistego. Obiekty te nie są, w przeciwieństwie do anemicznego modelu, pozbawione odpowiedzialności i łączą w sobie własności i zachowania realizujące logikę biznesową aplikacji. W warstwie zwanej konrolerem znajdują się pogrupowane w klasy procedury, które realizują poszczególne use casey aplikacji delegując odpowiedzialność do obiektów biznesowych - NIE ZAWIERAJĄ tym samym logiki biznesowej. Z procedur tych korzystają komponenty widoku umieszczone w warstwie prezentacji. Oczywiście dane w aplikacji przeważnie muszą być utrwalane, chociażby w relacyjnej bazie danych - tym zajmuje się warstwa Data management. Każdy obiekt biznesowy ma jakieś odzwierciedlenie w każdej z tych 4 warstw, więc każda zmiana czy nowa koncepcja biznesowa oznacza zazwyczaj modyfikacje w każdej z warstw, czyli mnóstwo pracy. Rozwiązaniem może być uczynienie warstw widoku i kontrolera całkowicie generycznymi. Pawson proponuje ograniczyć się jedynie do implementacji modelu domeny biznesowej i generować UI z obiektów biznesowych. W rezultacie architektura naszej aplikacji zaczyna wyglądać następująco:


Wygenerowany interfejs użytkownika jest zorientowany obiektowo (OOUI - Object Oriented User Interface). Oznacza to tyle, że użytkownik widzi na ekranie odpowiedniki obiektów dziedziny, może przeglądać/edytować ich własności oraz wysyłać do nich komunikaty tj. wywoływać ich metody. W oczywisty sposób wymusza to, żeby obiekty biznesowe miały odpowiedzialność - bye bye anemic model. Jeśli komuś trudno sobie wyobrazić po tym opisie jak wygląda obiektowe UI, to dodam, że z takim GUI mamy do czynienia na co dzień użytkując współczesne systemy operacyjne - zarówno microshitowe jak i linuxowe z dowolnym środowiskiem graficznym. Obiekty są reprezentowane w nich poprzez ikony na pulpicie, które są abstrakcją aplikacji, sprzętu, elementów systemu plików, itp. Używając menu kontekstowego możemy przeglądać własności poszczególnych obiektów i wywoływać na nich różne akcje. Zauważmy, że tak samo może być w przypadku aplikacji enterprise - użytkownik aby zrealizować jakiś biznesowy use case musi odszukać na UI obiekt(y) które posiadają potrzebną odpowiedzialność, wyedytować ich własności i/lub wywołać jakieś akcje być może przekazując do nich parametry. Obiekty, które użytkownik widzi na ekranie mają oczywiście swoje odpowiedniki w warstwie domenowej, stąd właśnie nazwa wzorca Naked Objects - obnażone dla użytkownika obiekty dziedziny biznesowej.

Podstawowym zadaniem frameworków implementujących wzorzec Naked Objects jest zatem generowanie interfejsu użytkownika na podstawie obiektów warstwy biznesowej. Wystarczy wskazać, które obiekty mają być udostępnione użytkownikowi. Na rynku mamy kilka Javowych narzędzi tego typu. Jednym z nich jest framework stworzony przez firmę samego Pawsona i nosi tę samą nazwę co wzorzec, czyli Naked Objects. Inne darmowe toole to: JMatter (nie mylić z JMetter), Trails, Sanssouci, Domain Object Explorer. W najbliższym czasie postaram się przyjrzeć bliżej niektórym z nich i zamieszczę tutaj swoje wrażenia.

Podsumowując, do najważniejszych zalet Naked Objects należą:

• NIE anemiczny model dziedziny biznesowej,
• Znaczne zwiększenie szybkości developmentu - implementujemy 1 warstwę, resztę robi automat,
• Wspólny język pomiędzy developerami, a użytkownikami - kwestia mocno podkreślana w DDD,
• Moc OOP w interfejsie użytkownika.

Jako wady wymienić należy:

• Brak możliwości zmiany wyglądu generowanego UI, ktróry całkowicie zależy od frameworka,
• Użytkowanie OOUI może wymagać więcej nauki niż użytkowanie tradycyjnego use case driven UI.

Powyższe wady i zalety wskazują, że wzorzec Naked Objects może być stosowany tylko wtedy, gdy nie ma absolutnie żadnych wskazań do ręcznego tworzenia UI i użytkownik końcowy będzie długotrwale korzystał z aplikacji.