Główne zasady DDD
Warto jednak podkreślić, że DDD to nie produkt, który można kupić i zainstalować jako biblioteki. To zbiór koncepcji, zasad i sprawdzonych praktyk, których można (i trzeba) się nauczyć. Omówmy kilka z nich.
Język wszechobecny (Ubiquitous Language)
To rdzeń komunikacyjny DDD. Chodzi o wypracowanie wspólnego, jednolitego słownictwa opisującego domenę, zrozumiałego dla wszystkich – od programistów po ekspertów domenowych. Powstaje on w wyniku ścisłej współpracy zespołu deweloperskiego z osobami dobrze rozumiejącymi logikę, cele i zasady obowiązujące w organizacji. Np. jeżeli w firmie ubezpieczeniowej mówi się o „polisie”, „szkodzie” i „ubezpieczonym”, to klasy i moduły w systemie również powinny nazywać się Polisa, Szkoda, Ubezpieczony, zamiast np. Record1, DataObject itp.
Bounded Context (Ograniczony kontekst)
Domena biznesowa często bywa rozległa i obejmuje różne aspekty działalności firmy. Bounded Context to koncepcja podziału dużej domeny na mniejsze, spójne obszary (konteksty), w których dane słowo ma jednoznaczne znaczenie. Przykładowo „zamówienie” może znaczyć co innego dla działu sprzedaży, a co innego dla magazynu – dlatego w DDD ważne, aby oddzielić kontekst „Sprzedaż” od kontekstu „Magazyn”, itd.
Przeczytaj także: Wizualizacja danych – czym jest i jakie narzędzia stosować?
Podział na entities, value objects i aggregates
W modelu domenowym entity, czyli encja, reprezentuje konkretny obiekt biznesowy, który ma swoją tożsamość i cykl życia. Klient lub zamówienie z unikalnym ID może być encją, która chociaż ma te same atrybuty (imię, adres), co inna encja, będzie mieć swoją historię odzwierciedlającą rzeczywiste zdarzenia biznesowe. Z encją wiążą się wartości obiektów (value objects), które opisują cechy lub atrybuty domenowe. Przykładami mogą być: Adres (określony przez ulice, kod, miasto itd.), Pieniądz (kwota wraz z walutą) czy Okres czasu (data od–do).
Z kolei agregat to grupa powiązanych ze sobą obiektów (entities + value objects). Ma on wyznaczoną główną encję – tzw. root entity, za pośrednictwem której zewnętrzne części systemu mogą oddziaływać na obiekty wewnątrz agregatu. Przykładowo, Zamówienie może być agregatem, gdzie zamówienie jest korzeniem, a związane z nim Pozycje zamówienia są encjami lub wartościami. Wszelkie operacje (dodanie pozycji, anulowanie zamówienia) przechodzą przez encję Zamówienie, co gwarantuje spójność – np. że łączna kwota zamówienia zawsze zgadza się z sumą pozycji.
Przeczytaj także: Technologie Low-Code i No-Code – czym są i jak działają?
Domain-Driven Design – FAQ
Na koniec podkreślmy jeszcze 3 aspekty związane z koncepcją DDD.
Czy Domain-Driven Design to konkretny framework lub technologia?
Nie. DDD to podejście i zbiór praktyk projektowych, a nie namacalny produkt czy framework, który wystarczy zainstalować. To bardziej sposób myślenia o architekturze systemu i modelowaniu logiki domenowej niż technologia.
W jakich projektach warto zastosować Domain-Driven Design?
Praktyczne zastosowanie DDD znajduje tam, gdzie logika biznesowa jest rozbudowana, pełna reguł, wyjątków i wzajemnych zależności, a wymagania biznesowe się zmieniają. Dobrze zaprojektowany model domeny i napisany pod niego kod ułatwi wprowadzanie nowych funkcjonalności przez lata – bez psucia starych.
Jak zacząć przygodę z DDD w istniejącym zespole lub projekcie?
DDD najlepiej zacząć od małych kroków. Można z działającego już projektu wydzielić fragment istotny biznesowo, a następnie z „osobami od biznesu” zbudować mini-język wszechobecny dla tego kontekstu. Kolejny etap to próba zaimplementowania zasady zgodnej z DDD w tym fragmencie, np. utworzenie encji z metodami zamiast procedur modyfikujących dane. Jednak w każdej fazie programowania konieczna jest ścisła współpraca z ekspertami domenowymi – ponieważ Domain-Driven Design to dogłębne zrozumienie procesów biznesowych i przełożenie ich na jakikolwiek język programowania.
Może Ci się spodobać:
4 min.
