DDD programowanie (Domain Driven Design) – czy warto stosować takie podejście do tworzenia oprogramowania w firmie?

Wraz z rozwojem infrastruktury informatycznej i postępu w dziedzinie rozwoju oprogramowania, firmy szukają coraz to nowych dróg, które umożliwiają relatywnie szybkie tworzenie bezpiecznych aplikacji i systemów, które  pokrywają wszystkie warunki, a jednocześnie są łatwe do testowania i rozwijania. Na kanwie prób i błędów stworzono podejście, które przez wiele organizacji jest traktowane jako idealny sposób tworzenia oprogramowania. Mowa o Domain Driven Design. Czym dokładnie jest takie podejście do tworzenia oprogramowania w firmie?

 

 

Domain Driven Design (DDD) – co to za podejście?

 

Na samym początku warto zdefiniować, czym dokładnie jest podejście DDD. Jest to sposób tworzenia aplikacji i systemów, które w głównej mierze powinny w jak najlepszy sposób odzwierciedlać potrzeby biznesu – a więc założenia biznesowe, które stają się jednocześnie warunkami koniecznymi zawartymi w oprogramowaniu. Warto na tym etapie podkreślić, że Domain Driven Design to metoda tworzenia oprogramowania, która jest wykorzystywana w największych biznesowych systemach informatycznych.

Jakie założenia przyświecają metodzie DDD? Przede wszystkim projektowanie każdego oprogramowania powinno opierać się na równej współpracy pomiędzy programistami i osobami związanymi bezpośrednio z biznesem, którzy jednocześnie bywają klientem docelowym rozwiązania. Drugi warunek tworzenia systemów metodą Domain Driven Design to projektowanie logiki projektu w postaci domen.

Czym jest domena? To w telegraficznym skrócie konkretny obszar biznesowy, który musi zostać zaimplementowany. Obszar, który ma zostać usprawniony za pośrednictwem nowo wytworzonego lub rozwijanego oprogramowania. W zależności od wagi i istoty konkretnego konceptu i funkcjonalności, domeny możemy podzielić na:

  • Domeny główne, które stanowią najważniejszą część systemu i odpowiadają za najważniejszą funkcjonalność.
  • Domeny wspierające, które są rozbudową domeny głównej – bez niej domeny wspierające są bezwartościowe.
  • Domeny generyczne, które stanowią ważne, acz dodatkowe funkcje.

 

 

Co składa się na DDD?

 

Proces tworzenia oprogramowania według zasad Domain Driven Design nieco różni się od tradycyjnego podejścia do wytwarzania oprogramowania, które obejmuje szereg zagadnień technicznych związanych z obsługą mechaniki, wejścia danych i ich wyjścia, komunikacji z serwerem, bazą danych i integracją z innymi narzędziami stosowanymi przez organizację.

Programowanie DDD składa się przede wszystkim z modelów domeny (domeny główne, wspierające i generyczne), które zawierają bardzo podstawową implementację wartości biznesowych, które muszą znaleźć się w oprogramowaniu. Bardzo istotne jest, by programista odpowiedzialny za tworzenie kodu dokładnie zrozumiał cel tworzenia oprogramowania i był świadomy wartości, jaką niesie za sobą dana domena. DDD nie może obyć się bez zdefiniowania języka, który pozwala na łatwe zrozumienie języka przez ekspertów domenowych i programistów. W przypadku tego podejścia język ten nazywany jest Ubiquitous language.

 

 

Jakie trudności mogą wystąpić z podejściem Domain Driven Design?

 

Jakie jest największe wyzwanie związane z wykorzystaniem podejścia Domain Driven Design? Przede wszystkim komunikacja pomiędzy biznesem a stroną techniczną. Co do zasady, w podejściu DDD zawsze powinno znaleźć się miejsce dla eksperta domenowego, który dysponuje biegłą wiedzą na temat podejścia i samodzielnie będzie pełnić funkcję „kompilatora” w komunikacji na linii biznes-IT.

Ze względu na relatywnie mały odsetek projektów tworzonych metodą Domain Driven Design, bardzo ciężko jest znaleźć osobę, która z pełnym zaangażowaniem może podjąć się takiej roli. Brak odpowiedniego doświadczenia programistów w tworzeniu z pomocą metodyki DDD również może powodować dodatkowe trudności.

 

 

Wady i zalety podejścia DDD

 

Zacznijmy od zalet wykorzystania podejścia Domain Driven Design w wytwarzaniu oprogramowania. Przede wszystkim jest to świetne rozwiązanie w przypadku skomplikowanych projektów, gdzie ilość funkcjonalności, celów ich wdrożenia i przeróżnych warstw jest na tyle duża, że ciężko objąć to konceptualnie podczas tradycyjnego projektowania aplikacji. Podejście DDD odpowiada na prawdziwe potrzeby biznesu – nie ma tutaj miejsca na półśrodki – jeśli jakaś domena jest odpowiednio zinterpretowana przez programistę, zostanie ona zaimplementowana w całkowitej zgodzie z potrzebami użytkownika końcowego. Warto jeszcze wspomnieć o relatywnie niskim koszcie rozwijania aplikacji, który od samego początku był tworzony według podejścia DDD.

A jakie wady przemawiają przeciw stosowaniu tej metodyki? Podstawowa wada to mała praktyka wykorzystania tego sposobu wytwarzania oprogramowania. To sprawia, że początki stosowania nowej z punktu widzenia zespołu projektowego strategii niesie za sobą ryzyko całkowitego niezrozumienia konceptu, a co za tym idzie, porażkę.

Początkowy koszt wytworzenia zaprojektowania i stworzenia aplikacji metodyką DDD jest wyższy, co z pewnością wpływa na mały odsetek projektów realizowanych w ten sposób.

 

 

Jak wykorzystać DDD we własnym projekcie?

 

By DDD mógł być wykorzystany w praktyce w naszym projekcie, musimy tak naprawdę rozpocząć pracę od nowa. Nie ma możliwości częściowego zaadaptowania koncepcji Domain Driven Design, gdzie reszta modelu zostanie zaprojektowana w sposób tradycyjny. W takim przypadku satysfakcja z produktu końcowego będzie niska zarówno po stronie zespołu IT, jak i użytkownika końcowego.

Bardzo ważne, by jeszcze przed rozpoczęciem pracy znaleźć eksperta domenowego, który doskonale zna specyfikę biznesu, jego potrzeby, i potrafi przekuć je na jasne instrukcje dla programistów. Wybór technologii tworzenia aplikacji w przypadku pracy z DDD schodzi tak naprawdę na drugi plan.