!FrAgile Thinking

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ą.