Domain Driven Design – Zastosowanie

Domain Driven Design ma wiele zastosowań, odnosi się do sposobu modelowania i projektowania projektu komunikacji między członkami zespołu i sprawnym prowadzeniem projektu. Nie narzuca technologii czy wymagań serwerowych. Praktycznie w każdym projekcie można wdrożyć DDD, jednak nie w każdym się to opłaca.

Drogi start, tańsza rozbudowa

Gdy pracuje się nad projektami, szczególnie tymi dużymi zauważam wiele wspólnych dla nich wszystkich cech. Im aplikacja jest większa tym trudniej jest dokonać zmiany. Mała zmiana, nierozważnie dokonana może ciągnąć za sobą ogromne konsekwencje w postaci awarii całego systemu. Z czasem dokonanie zmiany, która na początku projektu mogłaby zostać wykonana przez programistę, który dopiero wdraża się w tajniki, jest bardzo ciężka do wykonania przez doświadczony zespół programistów. Przy złym zarządzaniu projektem aplikacji, jego złożoność może doprowadzić do tego, że przestaniemy nad czymkolwiek panować.

W rozwiązaniu tego problemu bardzo skuteczne jest podejście Domain Driven Design. DDD aplikuje się do projektów, w których model:

  • Jest powodem tworzenia projektu.
  • Jest sercem systemu – najwyższa wartość.
  • Daje klientowi przewagę nad konkurencją.
  • Modelowanie w projekcie

DDD zakłada przede wszystkim, że baza danych nie jest w żadnym wypadku modelem. Odpowiednio zaimplementowany model DDD stanowi odpowiednią komunikację pomiędzy zespołem IT a biznesem. Aby bardziej obrazowo pokazać, czemu służy DDD można wyobrazić sobie wybór nowo tworzonego modelu samochodu.

Zostaje stworzony prototyp. Każda z osób, która będzie miała później pracować przy produkcji może się z nim zapoznać. Dzięki temu eksperci np. z zakresu aerodynamiki samochodu mogą stwierdzić, że należy zmienić konstrukcję, a eksperci od efektu wizualnego będą mogli do tego się odnieść. Tak przedstawiony projekt pozwoli się wypowiedzieć każdemu ekspertowi, ponieważ będzie dla niego czytelny oraz zrozumiały. W modelu DDD zastosowano jednak podstawowe reguły i zachowania. Zrobiono to w celu stworzenia „szkieletu” projektu. Każdy może go dostosować pod siebie. Warto jednak „szkielet” ten rozłożyć na czynniki pierwsze, aby łatwiej było zrozumieć, z czego jest on zbudowany. DDD złożone jest z kilku prostych technik, dzięki którym projekt jest zrozumiały dla wszystkich stron.

Techniki DDD

Pierwszą z technik jest język wszechobecnym lub przez niektórych zwany „wszędobylski”. Ekspert domenowy musi rozumieć w takim samym stopniu model projektu jak wszyscy pozostali członkowie. Dlatego też w projekcie musi istnieć wspólny model domeny. Jeżeli dany zespół pracuje ze sobą już nad drugim projektem, język ten powinien pozostać bez zmian – o ile oczywiście został już stworzony i działał dobrze w pierwszym projekcie. Nie można tutaj dokonywać jakichkolwiek rozróżnień na model analityczny, projektowy czy też deweloperski. Najtrudniejszym zadaniem jest utrzymanie wspólnego modelu na poziomie analizy oraz developmentu. Tutaj czasem mogą pojawiać się największe różnice.

Drugą z technik obecną w DDD jest szereg standardowych „klocków”, z których zbudowana będzie aplikacja. Pozwala to w niektórych wypadkach działać schematycznie, – co nie zwalnia nas oczywiście z obowiązku kontroli projektu. Zaczynamy tworzyć standardowe role dla obiektów, które będą wchodzić w skład modelu domenowego. Wyróżniamy:

O encjach, agregatach, fabrykach i repozytoriach pisałam szerzej we wcześniejszych postach. Polityka jest niczym innym jak wzorcem projektowym strategii. Nie chodzi tutaj, aby w projekcie była tylko jedna polityka, może ich być wiele, a także mogą się ze sobą łączyć. Polityki w pewnym sensie pozwalają modelowi na dalsze rozbudowy. Zdarzenia są bardzo istotnym elementem. Stosuje się je, gdy:

  • Należy dodać nowe funkcjonalności – architektura pluginowa.
  • Niezależne od siebie są dodatkowe czynności.
  • Jeżeli pewne czynności muszą wykonywać się asynchronicznie.
  • Jeżeli celem jest rozluźnienie powiązań pomiędzy obiektami z domen.

Dzięki technice Bounded Context można tworzyć różne modele, które będą opisywać te same byty, używane jednak w różnych kontekstach. Saga jest dosyć nowym blokiem DDD, pozwala ona na modelowanie procesów, w których dochodzi do działania z kilkoma wydarzeniami, które zaczynają przebiegać w inny sposób, gdy zostaną razem zestawione – w zależności od konfiguracji.

Kiedy warto stosować Domain-Driven Design?

1. Zespół

Wprowadzenie DDD ma bardzo duży koszt na początku projektu. Jego zaletą jest późniejszy niższy koszt utrzymania i rozbudów. Jasne jest, że DDD sprawdzi się w większych projektach, które będą się dynamicznie zmieniać, aby móc odczuć ten zysk z pracy włożonej na początku projektu. Budżet musi być również odpowiednio wysoki, aby w zespole znalazł się chociaż jeden programista z doświadczeniem w wdrażaniu DDD oraz cały zespół musi być przekonany o słuszności wdrożenia tego podejścia. Z doświadczenia wiem że brak osoby z praktyczną wiedzą w zespole źle się skończy, ponieważ każdy programista rozumie implementacje dziedziny trochę inaczej i jeśli nie ma osoby, która trzymałaby projekt w ryzach, z czasem logika domenowa rozpłynie się po innych warstwach systemu.

2. Skomplikowany projekt

Logika dziedziny projektu musi być wystarczająco skomplikowana i złożona, aby implementując model znaleźć przestrzeń na wprowadzenie kontekstów i innych elementów modelu. Kod logiki domenowej jest zazwyczaj bardzo złożony, posiada wiele warstw abstrakcji, aby jak najlepiej odwzorować rzeczywistość. W mniejszych projektach, gdzie logika nie jest skomplikowana koszt zaimplementowania abstrakcji dziedziny będzie sztuką dla sztuki, ponieważ ta sama logika mogłaby zostać napisana w paru klasach, między którymi nie występuje nawet zbyt wiele zależności.

W projektach, których logika opiera się np. na podstawowych CRUDach czy większości na różnych formularzach i ich obsłudze nie ma sensu wprowadzać DDD, ponieważ całą logikę można sprowadzić do obiektów DTO i przenoszenia danych między warstwą magazynowania danych a interfejsem. W takich sytuacjach de facto nie jesteśmy w stanie wydzielić domeny.

3. Jednolite podejście

Bardzo złym pomysłem jest częściowe wprowadzenie DDD do projektu. W przypadku, gdy tylko część logiki jest zaprojektowana i zaimplementowana w DDD, a reszta np. całkowitym dostosowaniu do frameworka, projekt jest bardzo ciężki do utrzymania. Kod jest chaotyczny, a zaimplementowany model staje się ogromnym obciążeniem wydajnościowym. Język i nazewnictwo są niejasne. DDD narzuca specyficzne podejście do obiektów co w połączeniu ze standardowymi wzorcami i frameworkami generuje sporo błędów i niepotrzebnych mapowań między obiektami. Sytuacja połączenia DDD z innym podejściem najczęściej wynika z niezgranego zespołu, gdzie każdy z członków ciągnie w swoją stronę, a lider czy PM nie potrafi zarządzać swoimi ludźmi tak, by obrali wspólną ścieżkę rozwoju projektu. Z takimi problemami na starcie projekt ma bardzo małe szanse powodzenia, wdrożenia go terminowo i zaspokojenia potrzeb klienta.

4. Komunikacja

Nad projektami o dużej złożoności pracuje zwykle duży zespół programistów lub nawet kilka zespołów. W takich projektach wyzwaniem jest nie tylko dobra komunikacja między przedstawicielami IT oraz biznesu. Dużo cięższym zadaniem jest jasna i zrozumiała komunikacja między zespołami. W środowisku IT funkcjonuje prawo Conway’a: „Systemy komunikacyjne w organizacji wpływają na architekturę systemu.” Podkreśla ono jak ważny jest dobry sposób komunikacji w firmie, ponieważ każdy problem odbije się na architekturze systemu. Podkreślam Każdy problem wewnętrzny organizacji odbija się na systemie, który tworzy i odwrotnie, każdy poważny problem architektoniczny systemu odbija się na relacjach w zespole.

Mam nadzieje, że pomogłam i po przeczytaniu tego tekstu jesteś już w stanie stwierdzić czy w Twoim projekcie przyda się DDD. Jeśli masz dodatkowe pytania, pisz śmiało!

Podobne posty

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.

Comments

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here