Wraz z rozwojem technologii informatycznych i rozwojem nowego oprogramowania firmy poszukują coraz większej liczby sposobów na stosunkowo szybkie tworzenie bezpiecznych aplikacji i systemów, które obejmują wszystkie warunki i są łatwe do testowania i rozwijania. Metodą prób i błędów stworzono podejście, które jest postrzegane przez wiele organizacji jako idealny sposób na tworzenie oprogramowania.
Chodzi o projektowanie oparte na domenie. Na czym dokładnie polega takie podejście do tworzenia oprogramowania w firmie?
Domain Driven Design (nazwa skrócona DDD) – co to za podejście?
Na samym początku warto zdefiniować, czym dokładnie jest podejście DDD. Jest to sposób budowania aplikacji i systemów, który w zasadzie powinien odzwierciedlać potrzeby biznesu – założenia biznesowe, które jednocześnie stają się warunkiem wstępnym zawartym w oprogramowaniu.
Jakie są dane wejściowe, na których opiera się metoda DDD? Przede wszystkim projektowanie dowolnego oprogramowania powinno opierać się na równej współpracy programistów z osobami bezpośrednio związanymi z biznesem, będącymi jednocześnie docelowym odbiorcą rozwiązania. Drugim warunkiem tworzenia systemów metodą DDD jest zaprojektowanie logiki projektu w postaci domen.
Co to jest domena? W dużym skrócie jest to specyficzny obszar biznesu, który należy wdrożyć. Obszar, który należy poprawić za pomocą nowo utworzonego lub opracowanego oprogramowania. W zależności od wagi i istoty danej koncepcji i funkcjonalności możemy podzielić domeny na:
- Główne domeny, które są najważniejszą częścią systemu i odpowiadają za najważniejszą funkcjonalność.
- Domeny wsparcia, które są rozszerzeniami domeny głównej – bez niej domeny wsparcia są bezwartościowe.
- Wspólne domeny, które są ważnymi, ale opcjonalnymi funkcjami.
Z czego składa się DDD?
Proces tworzenia nowego oprogramowania w oparciu o zasady Domain Driven Design różni się nieco od tradycyjnego podejścia do tworzenia oprogramowania, które obejmuje szereg zagadnień technicznych związanych z przetwarzaniem mechaniki, wprowadzaniem i wyprowadzaniem danych, komunikacją z serwerem, bazą danych oraz integracja z innymi narzędziami wykorzystywanymi przez organizację.
Programowanie DDD składa się głównie z modeli dziedzinowych (domeny głównej, podrzędnej i ogólnej), które zawierają bardzo podstawową implementację parametrów biznesowych, które powinny być zawarte w oprogramowaniu. Bardzo ważne jest, aby programista odpowiedzialny za tworzenie kodu dokładnie rozumiał cel tworzenia nowego oprogramowania i rozumiał wartość, jaką niesie domena. DDD nie może obejść się bez zdefiniowania języka, który pozwoli ekspertom dziedzinowym i programistom na łatwe zrozumienie tego języka. W tym podejściu język ten nazwano językiem wszechobecnym.
Jakie trudności mogą się pojawić podczas korzystania z podejścia Domain Driven Design?
Jaki jest największy problem w stosowaniu metody DDD? Przede wszystkim jest to komunikacja między biznesem a stroną techniczną. Zgodnie z ogólną zasadą, w podejściu DDD zawsze powinno być miejsce na eksperta dziedzinowego, który ma dogłębną wiedzę na temat tego podejścia i sam będzie działał jako „kompilator” w komunikacji biznesowej i informatycznej.
Ze względu na stosunkowo niewielki odsetek projektów tworzonych metodą DDD bardzo trudno jest znaleźć osobę, która z pełnym zaangażowaniem mogłaby podjąć się takiej roli. Brak doświadczenia programistów w tworzeniu z wykorzystaniem metodyki DDD może również powodować dodatkowe trudności.
Zalety i wady podejścia DDD
Zacznijmy od korzyści płynących z zastosowania podejścia Domain Driven Design podczas tworzenia nowego oprogramowania. Przede wszystkim jest to świetne rozwiązanie dla złożonych projektów, gdzie liczba funkcji, celów implementacji i różnych poziomów jest tak duża, że trudno to koncepcyjnie uchwycić w tradycyjnym projektowaniu aplikacji. Podejście DDD wychodzi naprzeciw realnym potrzebom biznesu – nie ma miejsca na półśrodki – jeśli domena zostanie poprawnie zinterpretowana przez programistę, zostanie wdrożona w pełnej zgodności z potrzebami użytkownika końcowego. Warto również zwrócić uwagę na stosunkowo niski koszt rozwoju aplikacji, która od samego początku tworzona była zgodnie z podejściem DDD.
Jakie są wady korzystania z tej techniki? Główną wadą jest niewielka praktyka w stosowaniu tego sposobu tworzenia nowego oprogramowania. Z tego powodu rozpoczęcie stosowania nowej strategii, z punktu widzenia zespołu projektowego, niesie za sobą ryzyko całkowitego niezrozumienia koncepcji iw efekcie niepowodzenia.
Wyższy jest początkowy koszt produkcji projektowania i budowy aplikacji w metodyce DDD, co z pewnością wpływa na niewielki odsetek projektów, które są realizowane w ten sposób.
Jak używać DDD we własnym projekcie?
Aby DDD było praktyczne w naszym projekcie, musimy zacząć właściwie od zera. Nie jest możliwe częściowe zaadoptowanie koncepcji Domain Driven Design, w której reszta modelu zostanie zaprojektowana w tradycyjny sposób. W takim przypadku satysfakcja z finalnego produktu będzie niska zarówno ze strony zespołu IT, jak i końcowego użytkownika.