Domain Driven Design – DDD co to takiego?

Tym oto wpisem zapraszam Cię na serię o DDD. Chciałabym w pełni przedstawić temat w przystępny sposób. Przykłady będę prezentować w języku PHP, ponieważ przede wszystkim to język, w którym na co dzień pracuję, a po drugie mało jest przykładów w internecie właśnie w tym języku. Historia Domain Driven Design jest ściśle powiązana z Javą, więc połączenie go z PHP wydaje mi się jeszcze ciekawsze. Dlatego dzisiaj zachęcam Cię do poznania krótkiego zarysu koncepcji DDD a w następnych postach będziemy pracować na konkretnych przykładach.

Zacznijmy więc od  koncepcji projektowania zgodnie z Domain-Driven Design oraz pokrótce warto opowiedzieć historię jej powstania.

Domain Driven Design

Domain Driven Design to podejście do projektowania systemów, które kładzie duży nacisk na jak najlepsze odzwierciedlenie procesów i założeń biznesowych w implementacji. Obiekty i ich relacje powinny jak najbardziej odzwierciedlać biznes, a nazewnictwo powinno być spójne z językiem biznesowym. Najważniejsze założenia DDD to:

  • Logika projektu powinna zostać opisana w modelu domenowym.
  • Projektowanie systemu powinno być nastawione na współpracę między zespołem technicznym a ekspertami domenowymi, czyli osobami po stronie klienta.

DDD daje nam narzędzia, struktury i terminologię, które możemy wykorzystać w procesie podejmowania decyzji projektowych. Jest zestawem koncepcji i technik wspierających projektowanie i implementację modeli biznesowych.

Zespół projektowy obejmuje oprócz osób, które naturalnie przychodzą nam do głowy jak PM, developerzy czy testerzy także eksperta domenowego. Czasami nazywany również ekspertem dziedzinowym Nie tworzy on oprogramowania, ale zajmuje się dziedziną aplikacji. Jest bazą wiedzy dla developerów. Ma pełną wiedzę na temat procesów, które mają zostać zaimplementowane. Najczęściej jest to osoba po stronie klienta, która wspiera programistów i architektów. Jest głównym źródłem wiedzy na temat biznesu. Nie wolno mylić go jednak z analitykiem.

Garść historii

W 2003 roku, na rynku pojawiła się książka Erica Evansa książki pt. Domain-Driven Design. Zapanuj nad złożonym systemem informatycznymTo właśnie wtedy szerokie grono programistów usłyszało o DDD. Ciekawe jest to, że w świecie IT, gdzie wszystko szybko staje się nieaktualne, ta książka od 10 lat dalej jest biblią tego podejścia i nadal jest w pełni aktualna. Dwa lata temu 80% prezentacji na PHPConie dotyczyła właśnie DDD. Był to bardzo gorący temat.

Pierwszy raz spotkałam się z DDD jakieś 3 lata temu, gdy dostałam do utrzymania aplikacje opartą na tym podejściu. Była to dla mnie czarna magia. Jednak po bliższym poznaniu, polubiłam taką strategię projektowania systemów. Moja praca z tą aplikacją skłoniła mnie do napisania pracy magisterskiej właśnie na ten temat. Bardzo chciało mi się śmiać, gdy mój recenzent nie bardzo zrozumiał, co to jest. Był to starszy Pan, który zatrzymał się na Asemblerze, ale bardzo go szanuje, że tak dzielnie walczył, próbując zadać sensowne pytanie.

Co to ta domena?

Domena to obszar tematyczny, sfera wiedzy, która ma zostać zaimplementowana. Tworzone na jej podstawie oprogramowanie ma usprawnić procesy, które w niej regularnie zachodzą. Najczęściej w dużych firmach, zatrudniających wielu pracowników, pojawia się  potrzeba stworzenia oprogramowania, które usprawni i przyspieszy prace ludzi. Przedsiębiorstwa chcą podkręcić wydajność swoich pracowników, ale nie kosztem ich życia prywatnego czy zdrowia. W korporacjach złożoność domeny jest duża, jednak same procesy są wykonywane zawsze w tych samych warunkach, a ich przebieg jest stały i można go jednoznacznie opisać. A jeśli da się go opisać to i możliwa jest jego implementacja.

Gdy firma zgłasza się do firmy informatycznej, aby stworzyła jej aplikację dedykowaną, architekt jedzie do firmy, rozmawia z ludźmi i patrzy, jak na co dzień pracują. To trochę przeniesienie pracy UX na architekturę systemu, nie tylko na interfejs graficzny.

Mam nadzieję, że już teraz wiesz czym jest DDD. Na razie to tylko garść teorii, ale już w następnej części będzie więcej konkretów o obiektach i wzorcach, które są zalecane w tym podejściu.

Pracowałeś kiedyś w DDD? Znasz to podejście? Jesteś zwolennikiem czy przeciwnikiem? Daj znać w komentarzu!

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