INYNIERIA OPROGRAMOWANIA

Sawomir Sobtka

Domain Driven Design krok po kroku

Cz II: Zaawansowane modelowanie DDD
techniki strategiczne: konteksty i architektu-
ra zdarzeniowa
Modele nietrywialnych domen wymagaj struktury. Struktury, ktra pomaga nam
okiezna chaos. W zestawie technik DDD znajduj si podejcia strukturyzacji sys-
temu na kadym poziomie abstrakcji. Techniki DDD stanowi rwnie rusztowania
mentalne, ktre prowadz procesy mylowe modelarza w kierunku bardziej ade-
kwatnych modeli. W artykule zostan przedstawione techniki destylacji domen, wy-
dzielania kontekstw, komunikacji pomidzy kontekstami, porzdkowania zoonych
kontekstw oraz na poziomie mikro efektywnego modelowania Agregatw.

Plan serii w struktur, ktra separuje elementy modelu wg ich po-

Niniejszy tekst jest drugim z serii artykuw majcych na celu
szczegowe przedstawienie kompletnego zestawu technik
modelowania oraz nakrelenie kompletnej architektury apli-
kacji wspierajcej DDD.
Cz 1: Podstawowe Building Blocks DDD;
Cz 2: Zaawansowane modelowanie DDD techniki stra-
tegiczne: konteksty i architektura zdarzeniowa;
Cz 3: Szczegy implementacji aplikacji wykorzystujcej
DDD na platformie Java (dwa podejcia: Spring i EJB 3.1 oraz
JPA);
Cz 4: Skalowalne systemu w kontekcie DDD - architek-
tura CqRS;
Cz 5: Kompleksowe testowanie aplikacji opartej o DDD;
Cz 6: Behavior Driven Development - Agile drugiej ge-
neracji
datnoci na zmiany.
Na zakoczenie naszych rozwaa powrcimy do oma-
wianych w poprzedniej czci Agregatw i zastanowimy
si nad ich granicami. Poznamy techniki efektywnego
modelowania granic Agregatw oraz typowe bdy.
DESTYLACJA CORE DOMAIN - KIEDY
NIE STOSUJEMY DDD
Stosowanie technik DDD wnosi pewien narzut w procesie
tworzenia oprogramowania. Narzut ten jest inwestycj,
ktra jednak nie zwraca si w kadym przypadku. Dla-
tego na wstpie modelowania DDD okrelamy miejsca w
systemie, w ktrych stosujemy techniki DDD, oraz miej-
sca, w ktrych ich nie stosujemy.
Supporting Domain wiadomy dug techniczny

STRATEGICZNA STRUKTURYZACJA Relatywnie proste domeny nie wymagaj technik DDD

RNE SKALE, JEDEN CEL
Wszystko jest na miejscu i wszystko ma swoje miejsce
- cytat Benjamina Franklina jest chyba najlepszym pod-
sumowaniem strategicznych technik DDD.
Pierwsz decyzj, jak podejmujemy podczas modelo-
wania z wykorzystaniem DDD, jest okrelenie tych miej-
sce w caej rozcigoci systemu, w ktrych bdziemy
stosowa techniki DDD.
Kolejnym poziomem strukturyzacji jest wydzielenie ja-
snych granic Bounded Context kontekstw, w ktrych
obowizuj osobne modele.
Separacja modeli jest ze wszech miar poyteczna, jed-
nak zwykle rodzi problem: domeny musz ze sob wsp-
pracowa. Zatem zastanowimy si, jak technicznie doko-
na mapowania kontekstw. Poszczeglne modele mog
by wci zoone, dlatego nadamy im gbsz - warstwo-
ich modelowanie z definicji nie wymaga zoonego proce-
su mentalnego. Moemy je z powodzeniem zaimplemen-
towa w uproszczonej (1,2 warstwowej) architekturze.
Zwykle okazuje si, e nad prostymi domenami wykonu-
jemy jedynie operacje CRUD (Create, Read, Update, De-
lete), zatem warto skorzysta z mnogoci wyboru frame-
work'w pozwalajcych generowa niemal automatycznie
aplikacje klasy przegldarka do bazy danych.
Te relatywnie proste domeny nazywamy Supporting
Domain. W tych miejscach systemu decydujemy si na
kompromisy jakociowe (jako modelu, jako kodu)
wiadomie zacigamy dug techniczny.
Przykadowo w naszym systemie moemy zdecydowa
si na wprowadzenie systemu komentarzy. Zakadajc,
e jego dziaanie nie jest krytyczne dla powodzenia cae-
go przedsiwzicia biznesowego, klasyfikujemy ten pod-
system jako Supporting Domain. Warto zwrci uwag,

22 /1 . 2012 . (1) /

e w innym kontekcie podsystem komentarzy moe by
krytyczny (poniewa np. buduje zaufania) wwczas
traktujemy go jako Core Domain.
Generic domain modele domen bazowych
Pewne domeny s generyczne w stosunku do naszej
gwnej domeny. Przykadowo tworzc system sucy do
handlu zawartoci multimedialn, nie bdziemy skupia
wysiku mentalnego, pracujc nad moduem fakturowa-
nia. Fakturowanie jest krytyczne (zaley nam na jakoci
tego moduu), ale a) nie stanowi ono gwnej wartoci,
oraz b) tego typu systemy istniej na rynku (zarwno
Open Source, jak i komercyjnym). Dlatego przykadowe
fakturowanie moemy potraktowa jako Generic Domain.
Z podsystemami zaliczanymi do Generic Domains inte-
grujemy si w taki sposb, aby ich modele nie przecie-
kay do naszego gwnego modelu.
Innym przykadem Generic Domain moe by biblio-
teka do operowania na Grafach. By moe bdziemy j
wykorzystywa w Module Magazynowym, aby sugerowa
najkrtsze cieki, jakimi naley si porusza pomidzy
regaami w magazynach, aby jak najszybciej skomple-
towa zamwienie. W tym przypadku nadbudowujemy
domen Magazynu (regay, pki, korytarze) nad gene-
ryczn domen grafw (wzy, cieki, algorytmy wyszu-
kiwania cieek).
Core Domain miejsce dla DDD
Omwilimy rodzaje domen, dla ktrych nie stosujemy
technik DDD. Techniki DDD maj zastosowanie (jako in-
westycja) w Core Domain. Core Domain to sfera logiki
biznesowej, ktra jest gwnym powodem, dla ktrego
system powstaje. By moe model z Core Domain sta-
nowi przewag systemu (klienta zamawiajcego system)
nad konkurencj. W Core Domain inwestujemy czas na-
szych najlepszych ludzi Developerw oraz Ekspertw
Domenowych. W DDD zakadamy, e modelowanie Core
Domain stanowi najwiksze wyzwanie w cyklu produk-
cji systemu. Zakadamy rwnie, e saby model stanowi
wysokie ryzyko niepowodzenia przedsiwzicia.
Podstawow technik destylacji Core Domain jest
spisanie Dokumentu Wizji. Dokument ten powinien by
krtki (np. 1/2 A4), dziki temu skoni jego twrc do
skupienia si na gwnych (Core) zaoeniach, ktre zwy-
kle dokadnie mapuj si na czynniki przewagi, czyli Core
Domain.
GRANICE BOUNDED CONTEXT
GRANICE WSPLNEGO JZYKA
Drugim poziomem strukturyzacji modelu jest wydzielanie
Bounded Context kontekstw, do ktrych jest przypisa-
ny Ubiquitous Language. Przypomnijmy w tym miejscu:
istnienie wsplnego jzyka, ktrym posuguj si wszy- umieszczamy w tak zwanym Shared Kernel.
scy uczestnicy projektu od Eksperta Domenowego po
Developerw - jest jednym z gwnych zaoe DDD.
DOMAIN DRIVEN DESIGN KROK PO KROKU
Modele odseparowane przez Bounded Context nie
mog odnosi si do siebie wprost. S to niezalene byty,
ktre mog by rozwijane przez osobne zespoy. Oma-
wiane w dalszej czci Wzorce Architektoniczne pozwa-
laj na hermetyzacj modeli, ktra redukuje problemy
zwizane ze zmianami i pozwala na niezalene rozwijanie
modeli przez zespoy, ktre nie wchodz sobie w drog.
Projekt referencyjny (link w ramce w sieci) zawiera
3 przykadowe Bounded Context: Sales, CRM, Shipping.
W przypadku tego projektu BC odpowiadaj moduom
systemu.
Granice kompetencji Ekspertw domenowych
W systemach o wikszej skali mamy czsto do czynienia z
sytuacj, gdzie korzystamy z wiedzy wielu Ekspertw Do-
menowych. Eksperci ci specjalizuj si w hermetycznych
domenach (sferach) wiedzy. Moliwo komunikacji mery-
torycznej pomidzy ekspertami jest mocno ograniczona.
Przykadowo w kontekcie naszego przykadowego
modelu: Pojcie produktu w Module Sprzeday oznacza
co, co ma charakterystyk handlow, pewne atrybuty
promocyjne, by moe jest powizane z profilami beha-
wioralnymi klientw.
Natomiast w Module Magazynowym jest to przedmiot,
ktrego gwn cech jest przykadowo to, e zajmuje
okrelon przestrze na regaach i by moe wymaga
specjalnego traktowania podczas transportu.
Jedynie ubstwo naszego jzyka powoduje, e eksper-
ci domenowi socjalizujcy si w sprzeday i eksperci spe-
cjalizujcy si w domenie magazynw uywaj podobnej
fali akustycznej, ktra brzmi produkt. Jednak na pozio-
mie znaczenia to brzmienie budzi zupenie rne skoja-
rzenia skojarzenia z pojciami pojawiajce si w umy-
le jednego eksperta s w ogle niedostpne dla umysu
innego eksperta.
Zatem prba uoglnienia i zsumowania kilku mode-
li wynikajcych z wiedzy osb o rozcznych kompeten-
cjach jest zajciem karkoomnym. W DDD takie podejcie
jest zaliczane do anty-wzorcw i nazywa si Corporate
Model Anti-Pattern.
Jeeli eksperci domenowi znajcy na wskro swe spe-
cjalizacje nie s w stanie si porozumie, to w jaki sposb
moemy sobie wyobrazi sytuacj, w ktrej developerzy
nie znajcy zwykle adnej z tych domen mog by w
stanie stworzy wsplny model kilku domen...?
Granice sownictwa Ekspertw Domenowych z Ubiquitous
Language wyznaczaj granice modeli - Bounded Context.
Techniki uwsplniania modeli
Cz poj jest wsplna dla wszystkich Bounded Con-
text. Przykadowo klasa Money z poprzedniego artykuu
modeluje pojcie, co do ktrego wszyscy Eksperci Dome-
nowi zgadzaj si w kadym szczegle. Wsplne pojcia
Inn technik uwsplniania modeli jest podejcie na-
zywane w DDD: Conformist. Polega na tym, e jeden
/www.programistamag.pl/ 23
 INYNIERIA OPROGRAMOWANIA
model jest zalenoci do drugiego. Czyli zmiany w jed-
nym modelu powoduj katastrof w drugim. Z tego
wzgldu jest to podejcie, ktrego rozwaenie zaleca
si w przypadkw projektw wspieranych przez zespoy
outsourcingowe.
WSPPRACA KONTEKSTW
W KIERUNKU ARCHITEKTURY
ZDARZENIOWEJ
Modele domen wyznaczone przez Bounded Context s
hermetyczne oznacza to, e pojcia z jednego modelu
nie wyciekaj do innych modeli. Jednak systemy maj
to do siebie, e ich skadowe musz wsppracowa.
W poprzedniej czci wprowadzilimy wstpny szkic
warstwowej architektury aplikacji. Nad warstw logiki do-
menowej umieszczamy logik aplikacji, modelujc Use
Case/Sser Story/Serwisy SAO. Poniej domeny umiesz-
czamy warstw infrastruktury, ktra zawiera midzy in-
nymi implementacje repozytoriw.
Zobaczmy, jak na bazie tych zaoe moemy podej
do komunikacji pomidzy Bounded Contexts.
Rysunek 1. Podejcia architektoniczne do wsppracy pomidzy Bounded Context
24 /1 . 2012 . (1) /
Wsppraca poprzez dane
W najbardziej podstawowym przypadku jeden BC po-
trzebuje pewnych danych z innego BC. W takim wypadku
komunikacj moemy modelowa poprzez Repozytoria.
Implementacja repozytorium w BC1 wywouje Serwis
Aplikacyjny (de facto API) BC2. Innymi sowy API BC2
staje si rdem danych w BC1. Pamitajmy, e z za-
oenia model domenowy nie wycieka ponad warstw
Serwisw Aplikacyjnych. Zatem komunikacja musi nast-
powa poprzez Obiekty Transferowe.
Dziki takiemu podejciu uzyskujemy hermetyza-
cj modeli. Model domeny BC2 nie jest znany w do-
menie BC1. Zesp pracujcy nad BC2, publikujc API,
podpisuje kontrakt ze wiatem zewntrznym i od
tej pory szczegem implementacyjnym jest sposb, w
jaki kontrakt ten jest speniony. Dziki temu model do-
meny BC2 moe rozwija si niezalenie i we wasnym
tempie.
Podejcie to rni si w zasadniczy sposb od popular-
nego podejcia, w ktrym moduy gmeraj sobie nawza-
jem w modelach danych.

Wsppraca poprzez operacje
Innym przypadkiem wsppracy BC jest wywoanie API
w celu wykonania pewnych operacji. Czyli nie operujemy
wprost na modelu domenowym innego BC, a wywoujemy
zbudowane nad nim API. Jest to klasyczna praktyka, ale
wspominamy o niej dla zachowania kompletnoci.
Wsppraca poprzez sygnay Zdarzenia
biznesowe
Wywoywanie serwisw z innych BC wprowadza silny Co-
upling. W przypadku wikszej iloci wsppracujcych ze
sob moduw skoczymy z Architektur o strukturze
klasycznego Spaghetti.
Klasyczn technik Decouplingu jest wprowadzenie
modelu zdarze. Zdarzenia s jedn z technik Inversion
of Control obok Dependency Injection i Aaspect Orien-
ted Programming. Musimy pamita jednak, e odwra-
cajc kontrol, jednoczenie j tracimy. Zatem zdarze
uywamy wwczas, gdy chcemy modelowa wspprac,
gdzie nie zaley nam na kontroli kolejnoci, czasu ani re-
zultatu wykonania.
W DDD przy pomocy zdarze modelujemy istotne z
biznesowego punktu widzenia fakty, ktre zaszy w cyklu
ycia Agregatu.
Listing 1. Zgoszenie zdarzenia w Bounded Context CRM w
Agregacie Customer
@Entity
public class Customer extends BaseAggregateRoot{
public enum CustomerStatus{
STANDARD, VIP, PLATINUM
}
@Enumerated(EnumType.STRING)
private CustomerStatus status;
public void changeStatus(CustomerStatus status){
if (status.equals(this.status))
return;
this.status = status;
eventPublisher.publish(
new CustomerStatusChangedEvent(
getEntityId(), status));
}
}
Listing 1 ilustruje przykad zgoszenia zdarzenia przez
Agregat Customer w momencie zmiany jego statusu.
Klasa CustomerStatusChangedEvent jest nonikiem in-
formacji o tym, ktry klient (ID) zmieni status. Mode-
lujc zdarzenia, musimy podj decyzj o tym, jakie in-
formacje umieszczamy w klasach zdarze w naszym
przykadzie jest to techniczne ID by moe lepsz de-
cyzj byoby przeniesienie informacji o biznesowym nu-
merze klienta...
Zdarzenie modeluje fakt, ktry mia miejsce i nie mo-
na go zawetowa moemy co najwyej zareagowa w
dodatkowy sposb na zaistniay fakt. Aby osign taki
DOMAIN DRIVEN DESIGN KROK PO KROKU
kontrakt na poziomie implementacji technicznej musi-
my posuy si transakcyjnym silnikiem zdarze, ktry
zagwarantuje nam, e zdarzenie zostanie propagowane
dopiero wwczas, gdy transakcja, w ktrej go wygenero-
wano, powioda si. Przykadem standardu wspierajcego
komunikaty transakcyjne jest Java Message Service.
Listing 2. Listener zdarzenia w Bounded Context Sales
listener znajduje si na poziomie aplikacji
@EventListeners
public class CustomerStatusChangedListener{
@EventListener(asynchronous=true)
public void handle(CustomerStatusChangedEvent
event) {
if (event.getStatus() == CustomerStatus.VIP){
calculateReabteForAllDraftOrders(
event.getCustomerId(), 10);
}
}
private void calculateReabteForAllDraftOrders(
Long customerId, int i) {
// TODO Auto-generated method stub
}
}
Listing 2 przedstawia kod jednego z Listenerw naszego
przykadowego zdarzenia. Listener ten wprowadza nast-
pujc funkcjonalno: jeeli w module CRM klient stanie
si VIPem, wwczas w module Sales nadajemy mu 10%
rabatu na wszystkie niezatwierdzone zamwienia.
Warto zwrci uwag na fakt, i nasz przykadowy Li-
stener posiada jedynie logik filtrowania zdarze, nato-
miast ca prac deleguje do Serwisu Aplikacyjnego (API)
swojego moduu. Jest to zatem jedynie kod klejcy.
Jak widzimy na Rysunku 1, nasz przykadowy Listener
jest klientem do API na takim samym poziomie jak np.
klienty GUI. Jest to zatem jeden z wielu aktorw, ktrzy
mog uruchamia API. Przykadowo rabaty na zamwie-
nia mog by naliczane nie tylko automatycznie podczas
promowania klienta do statusu VIP, ale rwnie rcznie,
poprzez GUI np. panelu administracyjnego.
Zdarzenia wprowadzamy do architektury systemu z
kilku powodw:
decoupling modeli opisany przykad
asynchroniczne wykonanie dodatkowych operacji
przykadowo w module CRM moemy wysya maile do
klientw, ktrych statusy zmieniono; wysyka maili to
czynno z jednej strony dodatkowa, a z drugiej poten-
cjalnie dugotrwaa
otwarcie architektury na pluginy wpinanie kolej-
nych listenerw mona potraktowa jako dodawanie
pluginw
rejestrowanie zdarze w celu ich przetwarzania i analizy
- np. z wykorzystaniem silnikw CEP (Complex Events
Processing) pozwalajcych na deklarowanie kwerend
filtrujcych okrelone wzorce zdarze w czasie
skadowanie zdarze jako modelu danych alternatyw-
nego dla bazy relacyjnej Event Sourcing
/www.programistamag.pl/ 25
 INYNIERIA OPROGRAMOWANIA

Saga model czasu w procesie biznesowym
Rozszerzeniem modelu zdarze jest Saga biznesowa.
Technicznie saga jest persystentnym multi-listenerem.
Oznacza to, e obiekty Sagi nasuchuj wielu zdarze
oraz ich stan jest utrwalany pomidzy kolejnymi zdarze-
niami z uwagi na potencjalnie dugi czas upywajcy
pomidzy kolejnymi zdarzeniami.
Natomiast na poziomie koncepcyjnym Saga modeluje
de facto czas.
Listing 3 zawiera przykadowy kod Sagi, ktra mode-
luje przepyw zamwienia. Saga reaguje na zdarzenia:
stworzenia zamwienia, zatwierdzenia zamwienia, na-
stpienia wysyki oraz dostarczenia zamwienia. Zakada-
my, e nie moemy przewidzie kolejnoci pojawienia si
tych zdarze, oraz czas pomidzy ich wystpieniem moe
siga miesicy.
Kada metoda nasuchujca konkretnego zdarzenia w
Sadze modyfikuje jej wewntrzny stan (wzorzec projek-
towy Memento) oraz sprawdza, czy warunki biznesowe
potrzebne do zakoczenia Sagi zostay spenione.
Wicej o Sagach na stronie projektu Levan oraz na
stronie szyny NServiceBus, ktra wspiera model Sag po-
przez API silnika.
POZIOMY MODELU OKIEZNA
CHAOS
Majc do czynienia ze zoonymi modelami, moemy potrze-
bowa dodatkowego rusztowania rozpinajcego struktur
modelu. Z czasem, gdy nasze rozumienie modelu pogbia
si, zauwaamy, e pewne jego elementy s oglnym fun-
damentem, na ktrym opieraj si specyficzne czynnoci.
Specyficzne czynnoci maj znowu swe wariacje.

Listing 3. Saga modelujca przepyw zamwienia

@Saga
public class OrderShipmentStatusTrackerSaga extends
SagaInstance<OrderShipmentStatusTrackerData> {

@Inject
private OrderRepository orderRepository;

@SagaAction
public void handleOrderCreated(OrderCreatedEvent event) {
data.setOrderId(event.getOrderId());
completeIfPossible();
}

@SagaAction
public void handleOrderSubmitted(OrderSubmittedEvent event) {
data.setOrderId(event.getOrderId());
// do some business
completeIfPossible();
}

@SagaAction
public void orderShipped(OrderShippedEvent event) {
data.setOrderId(event.getOrderId());
data.setShipmentId(event.getShipmentId());
completeIfPossible();
}

@SagaAction
public void shipmentDelivered(ShipmentDeliveredEvent event) {
data.setShipmentId(event.getShipmentId());
data.setShipmentReceived(true);
completeIfPossible();
}

private void completeIfPossible() {

if (data.getOrderId() != null
&& data.getShipmentId() != null
&& data.getShipmentReceived()) {
Order shippedOrder = orderRepository.load(data.getOrderId());
shippedOrder.archive();
orderRepository.save(shippedOrder);
markAsCompleted();
}
}
}

26 /1 . 2012 . (1) /
 DOMAIN DRIVEN DESIGN KROK PO KROKU

Rne czci modelu charakteryzuj si rn podat- Rozwarstwienie logiki to dopiero pocztek

noci na zmiany. Czytelnicy zaznajomieni z Archetypa-
mi Modeli Biznesowych znaj pojcie dwch poziomw
modelu: Operational Level i Knowledge Level. Natomiast
w DDD nadajemy modelowi jeszcze gbsz struktur i
wyaniamy w nim a cztery poziomy...
W poprzedniej czci dokonalimy rozwarstwienia logiki
na warstw aplikacji i warstw logiki domenowej. War-
stwa aplikacji modelu (czylu Use Case/User Story/Serwi-
sy SAO) jest odpowiedzialna za:

Rysunek 2. Poziomy modelu domenowego (wraz z mapowaniem na Archetypowe Operational i Knowlege Level)

/www.programistamag.pl/ 27
 INYNIERIA OPROGRAMOWANIA
orkiestracj domeny scenariusz sterowania obiekta-
mi domenowymi
dodatkow logik typow dla tej konkretnej aplikacji
technikalia takie jak transakcje i bezpieczestwo
Warstwa logiki domenowej to miejsce, w ktrym mode-
lujemy przy pomocy Building Blocks logik ograniczon
przez Bounded Context.
W tym rozdziale zajmiemy si dalsz strukturyzacj
zoonych modeli w warstwie logiki domenowej.
Capability
Poziom Capability zawiera klasy modelujce potencjalne
moliwoci, jakie oferuje nasz system. W naszym przy-
kadowym systemie umiecimy tutaj agregaty Product
i Client oraz Value Object Money. Posiadajc produkty,
uytkownikw i pienidze, moemy potencjalnie dalej
modelowa: handel, usugi, reklamacje itd. Na tym po-
ziomie zmiany s relatywnie niezbyt czste.
Operations
Poziom Operations zawiera klasy modelujce konkretne
operacje, jakie aktualnie wspiera nasz system. W na-
szym przykadowym systemie umiecimy tutaj agregaty
Order, Invoice oraz Serwis Biznesowy BookKeeper. Ska-
danie zamwie oraz wystawianie na ich podstawie przez
ksigowego faktur to konkretne operacje, jakie zbudowa-
limy nad modelem potencjau (produktami, klientami i
pienidzmi). Ten poziom jest rednio podatny na zmiany.
Policy
Poziom polityk niejako dostraja poziom Operacji. Przy-
kadowo Ksigowy (Serwis Domenowy BookKeeper) z
poziomu Operacji nalicza podatki na rne sposoby
w zalenoci od wdroenia systemu w rnych krajach
lub w zalenoci od tego, kto jest klientem na fakturze.
Zwrmy uwag, e sposb wybrania polityki (konfigura-
cja wdroenia bd decyzja w runtime) to funkcjonalno
aplikacji.
Obiekty na poziomie polityk modeluj wariacje operacji
biznesowych. Model ten jest mocno podatny na zmiany.
Warto zauway, e polityki na poziomie technicz-
nym to technicznie rzecz biorc domknicia Operacji.
Domknicia w sensie popularnych od pewnego czasu j-
zykw funkcyjnych. Natomiast w starszych jzykach im-
plementujemy je poprzez Wzorzec Projektowy Strategii
(zob. cz I).
Decission Support
Niektre systemy posiadaj rodzaj sztucznej inteli-
gencji - mniej lub bardziej wyrafinowane mechaniczny
analityczne wspierajce lub wrcz podejmujce decyzje.
W naszym przykadowym systemie mgby by to mo-
del sugerowania zamiennikw produktw w razie ich bra-
28 /1 . 2012 . (1) /
ku sugestie na postawie analizy behawioralnej klien-
ta, jego znajomych lub wszystkich klientw (polityka!).
Innym przykadem jest model dobierania rabatu (jeeli
klientowi przysuguje wiele rabatw, np z uwagi na: po-
zycj zamwienia, zawarto caego zamwienia, histori
zamwie klienta oraz dodatkowe rabaty: dla VIPw, z
okazji zimy itd.). Model dobierania rabatw moe by do-
strojony (policy!) tak, aby dziaa na korzy klienta lub
waciciela systemu...
GRANICE AGREGATW
MODELUJEMY NIEZMIENNIKI
Na zakoczenie omawiania zaawansowanego modelowa-
nia DDD poruszymy zagadnienie okrelania granicy Agre-
gatw. Jest to najwaniejszy aspekt modelowania DDD,
ktry decyduje o powodzeniu lub klsce modelowania.
Nieodpowiednio zakrelone granice Agregatw powo-
duj powstanie modeli sabo podatnych na zmiany oraz
nieefektywnych z wydajnociowego punktu widzenia.
W czci pierwszej przyjlimy dosy intuicyjne grani-
ce naszych Agregatw, natomiast teraz zastanowimy si
bardziej wiadomie nad ich modelem.
Czytelnicy dowiadczeni w modelowaniu DDD mogli
zwrci uwag na przykadowy Agregat Order, ktrego
granica bya zakrelona dosy chciwie, co mogo poten-
cjalnie powodowa problemy z utrzymaniem i wydajno-
ci modelu.
Agregat w definicji DDD jest spjn jednostk zmiany
(pracy). Od strony praktycznej Agregat powinien modelo-
wa i enkapsulowa w swym wntrzu niezmienniki. Przy-
kadowo, jeeli model domenowy zakada, e zawsze:
a+b=c
to wwczas Agregat powinien enkapsulowa a, b, c oraz
zapewnia, e po wywoaniu kadej metody Agregatu nie-
zmiennik jest zachowany. W naszym przykadowym Agre-
gacie Order modelujemy niezmienniki: 1) dodatnie/usu-
nicie produktu powoduje przeliczenie ceny po rabatach,
2) dodatnie produktu ju istniejcego nie powoduje poja-
wienia si nowej pozycji zamwienia, a jedynie zwiksze-
nie iloci na ju istniejcej pozycji.
Technika analizy przypadkw uycia
Dosy atwo moemy doprowadzi do nieodpowiednie-
go modelowania granicy Agregatw, jeeli zastosujemy
klasyczne podejcie polegajce na grupowaniu rzeczow-
nikw w worki. Przykadowo, jeeli odnajdziemy w
modelu rzeczownik Zamwienie, to wrzucamy do nie-
go kolejne, mniejsze rzeczowniki, tworzc zbyt duy
agregat.
Technik, ktra sprawdza si lepiej w DDD, jest po-
wstrzymanie si od wstpnego grupowania poj w tego
typu worki do momentu analizy przypadkw uycia/
operacji domenowych i grupowania ich pod ktem spj-
nych jednostek zmiany.
 DOMAIN DRIVEN DESIGN KROK PO KROKU

PODSUMOWANIE O CZYM NIE efektywne pobieranie danych Lazy Loading rozwizu-

POWIEDZIELIMY
Omwilimy kolejne poziomy strategicznego modelowa-
nia domeny, poczwszy od Destylacji Core Domen, czyli
miejsca, gdzie stosujemy techniki DDD, poprzez wya-
nianie na podstawie Ubiquitous Language granic mode-
lu Bounded Context, a po granice poszczeglnych
Agregatw.
Poruszylimy rwnie zagadnienie struktury wielko-
skalowej modelu, gdzie separujemy potencja modelu
od konkretnych operacji i modeli wspierajcych decyzje
oraz dostrajajcych je polityk. Kluczem nadawania tej
struktury jest zakres odpowiedzialnoci oraz podatno
na zmiany.
Warto zawrci uwag, i zbyt chciwie zakrelone
Agregaty powoduj nastpujce problemy:
je jedynie cz z nich
rwnolegym dostpem do danych im wicej danych
w agregacie, tym wiksze prawdopodobiestwo, e
wielu uytkownikw bdzie miao interes w jego rw-
nolegej modyfikacji; Optimistic Locking jedynie chroni
nas przed konsekwencjami, nie rozwizujc problemu
skalowanie jestemy zmuszeni, aby cay Agregat
persystowa w tym samym modelu danych oraz na tej
samej maszynie (zakadajc, e rozproszone transak-
cje s bdem w sztuce projektowania skalowalnych
systemw)
Zainteresowanych t tematyk odsyam do pierwszej
pozycji w ramce w sieci.

W SIECI:
PP strategiczne modelowanie agregatw: http://dddcommunity.org/library/vernon_2011
PP oficjalna strona DDD http://domaindrivendesign.org
PP wstpny artyku powicony DDD http://bottega.com.pl/pdf/materialy/sdj-ddd.pdf
PP przykadowy projekt: http://code.google.com/p/ddd-cqrs-sample/
PP sagi w NServiceBus http://www.nservicebus.com/sagas.aspx

Sawomir Sobtka slawomir.sobotka@bottega.com.pl

Programujcy architekt aplikacji specjalizujcy si w technologiach Java i efektyw-

nym wykorzystaniu zdobyczy inynierii oprogramowania. Trener i doradca w firmie
Bottega IT Solutions. W wolnych chwilach dziaa w community jako: prezes Stowar-
zyszenia Software Engineering Professionals Polska (http://ssepp.pl), publicysta w
prasie branowej i blogger (http://art-of-software.blogspot.com).

/www.programistamag.pl/ 29