馃憠 Domain Driven Design 馃槺

Z pewno艣ci膮 DDD nie jest dla ka偶dego. Je偶eli dopiero zaczynasz swoj膮 艣cie偶k臋 programisty to koncepty poruszane w tym artykule prawdopodobnie do Ciebie nie trafi膮. Mimo wszystko zach臋cam do lektury.


Cze艣膰聽馃檪

Techniki DDD zyska艂y sw膮 popularno艣膰 w roku 2003, wraz z publikacj膮 ksi膮偶ki Erica Evansa. Mimo up艂ywu lat koncepcja DDD jest wci膮偶 偶ywo rozwijana i wzbogacana o nowe techniki.

W dzisiejszym artykule:


Zrozumie膰 DDD

Domain Driven Design jest zestawem technik i koncepcji s艂u偶膮cych do projektowania z艂o偶onych modeli biznesowych i ich dos艂ownej implementacji. Naszym zadaniem, jako programist贸w jest zrozumienie faktu, i偶 technologia w jakiej rozwi膮zujemy problem nie jest istotna. Nasza uwaga powinna skupia膰 si臋 na biznesie. D膮偶ymy do zrozumienia warto艣ci biznesu, tego co robimy i w jaki spos贸b przek艂ada si臋 to na $.

Fundamentalnym zagadnieniem DDD jest relacja biznes <=> zesp贸艂. Kod, wytwarzany przez zesp贸艂 musi opiera膰 si臋 na domenie w jakiej pracujemy. Ka偶da domena ma jakie艣 regu艂y, walidacje, kompromisy – generalnie zasady biznesowe. I tu pojawia si臋 pierwsza 艣ciana – musimy pozna膰 domen臋. W jaki spos贸b poznaje si臋 domen臋 opisz臋 w kolejnym artykule – na dzi艣 niech wystarczy Ci wiedza, 偶e musisz znale藕膰 osob臋 / osoby, kt贸re bardzo dobrze znaj膮 problem od strony biznesu.

Tak jak na obrazku powy偶ej – domena b臋dzie si臋 zazwyczaj sk艂ada艂a z kilku subdomen. Podczas odkrywania domeny z biznesem b臋d膮 pojawia艂y si臋 zarysy, kt贸re na podstawie do艣wiadczenia / przeczucia / konsultacji z innymi b臋dziesz definiowa艂.

A zatem jak rozumie膰 Domain Driven Design? Wyr贸偶ni艂bym tutaj 3 g艂贸wne zasady, DDD:

  • koncentruje si臋 na podstawowej domenie i logice domeny
  • opiera z艂o偶one projekty na modelach domeny (to domena jest najwa偶niejsza)
  • polega na wsp贸艂pracy z ekspertami dziedzinowymi w celu ulepszania modelu aplikacji i rozwi膮zywania wszelkich pojawiaj膮cych si臋 problem贸w zwi膮zanych z domen膮

Podstawowe koncepty DDD

Kiedy czytamy o DDD na pewno spotkamy si臋 z poj臋ciem Ubiquitous Language. W praktyce oznacza to wsp贸lny j臋zyk modelu, kt贸rym pos艂uguje si膮 ca艂y zesp贸艂, pocz膮wszy od eksperta domenowego po programist贸w warstwy logiki domenowej. Jest to przy okazji jedna z zalet aplikacji opartych o projektowanie domenowe.

Innym konceptem s膮 Bulding Blocks, czyli j臋zyk standardowych wzorc贸w, z kt贸rych budujemy modele. Tutaj pozwol臋 sobie skopiowa膰 cz臋艣膰 artyku艂u bottegi, kt贸ra jest zreszt膮 doskona艂膮 lektur膮 DDD (w wi臋kszo艣膰 koncept贸w wejdziemy z czasem):

  • Entity 鈥 identyfikowalne obiekty zawieraj膮ce odpowiedzialno艣膰 biznesow膮;
  • Aggregate 鈥 hermetyczne grafy obiekt贸w, z jedn膮 encj膮 b臋d膮c膮 鈥瀔orzeniem agregatu鈥, kt贸ra stanowi API ca艂o艣ci. Agregat jest g艂贸wn膮 jednostk膮 logiki domenowej w DDD;
  • Value Object 鈥 wrapper dla typ贸w prostych, nadaj膮cy im znaczenie biznesowe oraz wygodny interfejs;
  • Service 鈥 specyficzne operacje, kt贸re nie pasuj膮 do 偶膮dnego agregatu;
  • Policy 鈥 model wariacji operacji biznesowych, Strategy Design Pattern;
  • Specification 鈥 model z艂o偶onych warunk贸w biznesowych, wywodzi si臋 z Composite Design pattern;
  • Event 鈥 model wydarze艅 biznesowych, mo偶e s艂u偶y膰 do przetwarzania r贸wnoleg艂ego lub komunikacji pomi臋dzy Bounded Context;
  • Saga 鈥 model z艂o偶onego procesu, kt贸ry stan jest trwa艂y oraz zale偶y od wielu zdarze艅;
  • Factory 鈥 tworzy nowe instancje z艂o偶onych Agregat贸w, dbaj膮c o ich poprawno艣膰. Zwi臋ksza testowalno艣膰, bior膮c niejako na siebie operatory new;
  • Repository 鈥 zarz膮dza trwa艂o艣ci膮 Agregatu/Encji.

Trudno艣ci zwi膮zane z DDD

Podstawowym problemem jest komunikacja i znalezienie eksperta domenowego. Je偶eli takiej osoby nie ma to nic nie wyczarujemy. Mo偶emy zgadywa膰 jak ma wygl膮da膰 domena ale to nie jest dobre rozwi膮zanie. Pr臋dzej lub p贸藕niej oka偶e si臋, 偶e pomylili艣my koncept i nie o to chodzi艂o biznesowi – a wtedy zmiany mog膮 by膰 bolesne…

Kolejn膮 trudno艣ci膮 s膮 kompetencje zespo艂u developerskiego. Je偶eli 偶aden z programist贸w ca艂kowicie nie wie o co chodzi w DDD to prawdopodobnie nic z tego nie wyjdzie. Albo i wyjdzie ale ogromnym kosztem. Na szcz臋艣cie jest kilka przyk艂adowych projekt贸w w sieci na bazie kt贸rej mo偶emy czerpa膰 wiedz臋 i inspiracj臋.

Cho膰 ten przyk艂ad w dzisiejszych czasach nie stanowi ju偶 a偶 tak wielkiego problemu to mimo wszystko warto o tym wspomnie膰. DDD wymaga pracy w procesie iteracyjnym. Domena jest 偶ywa – dochodz膮 nowe regu艂y, inne si臋 zmieniaj膮, zmienia si臋 prawo. To kieruje projekty rozwijane w metodologii DDD do bycia agile.

DDD nie pasuje wsz臋dzie. Techniki te s膮 op艂acalne dla projekt贸w operuj膮cych na z艂o偶onych i nietrywialnych domenach. Nie ka偶dy projekt jest na tyle skomplikowany, 偶e musimy ich u偶ywa膰 . Je偶eli mamy prosty proces CRUD’owy z zerow膮 lub marginaln膮 warstw膮 regu艂 biznesowych to osadzenie domeny (ciekawe czym ona jest w takim crudzie) tylko niepotrzebnie skomplikuje projekt. Nie po to pojawi艂 si臋 koncept Domain Driven Design.


Podsumowanie

Projektowanie oparte na domenie to podej艣cie in偶ynierii oprogramowania do rozwi膮zywania konkretnego modelu domeny. Rozwi膮zanie kr膮偶y wok贸艂 modelu biznesowego, 艂膮cz膮c wykonanie z kluczowymi zasadami biznesowymi. W du偶ych projektach zwykle tylko cz臋艣膰 modelu (Core Domain) b臋dzie spe艂nia膰 warunek gdzie DDD powinno by膰 zastosowane. Moim zdaniem jest to jak najbardziej poprawne aby tylko dla cz臋艣ci projektu zastosowane by艂o to podej艣cie. Jasne jest, 偶e wp艂ywaj膮 na to inne czynniki, np. kompetencje zespo艂u :).

殴r贸d艂a:


Za tydzie艅

Lecimy w 艣wiat DDD – om贸wimy w jaki spos贸b poznawa膰 domen臋.

0 0 vote
Article Rating
Subscribe
Powiadom o
guest
1 Komentarz
najnowszy
najstarszy oceniany
Inline Feedbacks
View all comments
Bartek Chmielewski
28 dni temu

Podstawowym problemem z DDD w艣r贸d programist贸w jest skupienie si臋 na wzorcach taktycznych. Natomiast warto艣膰 biznesowa le偶y gdzie indziej 馃槈