INYNIERIA OPROGRAMOWANIA

Sawomir Sobtka

Domain Driven Design krok po kroku

Cz IVa: Skalowalne systemy w kontekcie DDD
- architektura Command-query Responsibility Se-
gregation (stos Write)
Czy moliwe jest stworzenie systemu, ktry bdzie charakteryzowa si otwartym
na rozbudow modelem, eleganckim, testowalnym i utrzymywalnym kodem, a jed-
noczenie bdzie przygotowany do skalowania? Czy narzdzia typu Object-relatio-
nal mapper s panaceum na wszystkie problemy persystencji w systemach bizneso-
wych? Czy baza relacyjna to zawsze najlepszy pomys na przechowywanie danych?
Na te i inne pytania odpowiemy sobie w kolejnej odsonie naszej serii.

WSTP Plan serii

Po omwieniu oglnej idei DDD, technik zarwno taktycznego,
jak i strategicznego modelowania oraz sposobw wykorzysta-
nia popularnych frameworkw przyszed czas na przyjrzenie
si architekturze systemu jako caoci. Zakadamy, e tworzy-
my system, co do ktrego postawiono nastpujce wymagania
niefunkcjonalne:
PP dostp poprzez wiele technologii klienckich: web (w tym
ajax), mobile, web service...,
PP skalowanie poszczeglnych moduw (w sensie wydzielo-
nych jako produkty funkcjonalnoci) w celu zapewnienia
wydajnoci,
PP odporno na awarie pojedynczych moduw system jako
cao pozostaje stabilny,
PP stworzenie platformy otwartej na rozszerzenia poprzez wpi-
nanie pluginw.
W celu spenienia tych wymaga:
PP zrewidujemy tradycyjne podejcie do architektur warstwo-
wych, rozwijajc je w kierunku Architektury Porst & Adapters
(ramka W sieci),
PP zastanowimy si nad kwesti spjnoci danych kiedy jest
ona krytyczna, a w jakich wypadkach moemy pozwoli so-
bie na chwilow niespjno, zyskujc skalowalno,
PP przyjrzymy si miejscu, jakie Object-relational Mapper zaj-
muje w systemie oraz kiedy jego wykorzystanie nie jest
racjonalne,
PP zastanowimy si nad odpowiednimi modelami danych i ich
formami,
PP powrcimy do zagadnienia zdarze omawianych w poprzed-
nich czciach, aby wykorzysta ich peen potencja,
PP Projekt referencyjny.
Wszystkich tych Czytelnikw, ktrzy ju teraz chcieliby zapo-
zna si z kolejnymi zagadnieniami naszej serii, zapraszam do
odwiedzenia strony projektu DDD&CqRS Laven, ktrej adres
znajduje si w ramce W sieci. Dostpne wersje:
Niniejszy tekst jest czwartym artykuem z serii majcej na celu
szczegowe przedstawienie kompletnego zestawu technik mo-
delowania oraz nakrelenie kompletnej architektury aplikacji
wspierajcej DDD.
Cz I: Podstawowe Building Blocks DDD;
Cz II: Zaawansowane modelowanie DDD techniki strategicz-
ne: konteksty i architektura zdarzeniowa;
Cz III: Szczegy implementacji aplikacji wykorzystujcej DDD
na platformie Java Spring Framework;
Cz IV: Skalowalne systemy w kontekcie DDD architektura CqRS;
Cz V: Kompleksowe testowanie aplikacji opartej o DDD;
Cz VI: Behavior Driven Development Agile drugiej generacji.
PP Java Spring
PP Java EJB 3.1
PP .NET - C#
DWIE KLASY PROBLEMW
Typowy system klasy enterprise obsuguje dwa typy operacji:
PP rozkazy wykonujce pewne operacje biznesowe co prowa-
dzi zwykle do modyfikacji pewnej (relatywnie nieduej) iloci
danych, a w konsekwencji do koniecznoci utrwalenia tyche
zmodyfikowanych danych,
PP kwerendy (w tym kontekcie niekoniecznie w sensie SQL)
odpytujce cz danych skadowanych w systemie.
Statystycznie rzecz biorc, ilo obsugiwanych rozkazw do ilo-
ci obsugiwanych kwerend (w jakim interwale czasu) ma si
jak 1 do kilkustet (tysicy). Innymi sowy odczytw jest o kilka
rzdw wielkoci wicej ni zapisw miao moemy przyj,
e dla typowego systemu klasy enterprise moe by 5 rzdw
wielkoci.
Drugim aspektem obok statystycznego - ktry rni oba
typy operacji jest aspekt jakociowy modelu danych. Model da-
nych potrzebny do wykonania operacji na modelu biznesowym
oraz dane potrzebne do prezentacji wizualnej lub komunikacji z
innymi moduami to zwykle inne struktury.

66 /4 . 2012 . (4) /

Z uwagi na obszerno merytoryczn, czwart cz serii po-
dzielono na dwa osobne artykuy: niniejszy powicony Rozka-
zom oraz cz, ktra ukae si w przyszym miesicu i bdzie klienta biznesowego najwaniejsze s tabelki, w ktrych mona
powicona Kwerendom.
POTRZEBA SEPARACJI
Projektujc model danych, zwykle wybieramy podejcie Relacyj-
ne i skupiamy si na wsparciu dla modelu domenowego - czyli
dymy do Trzeciej Postaci Normalnej. Posta ta, ze wzgldu na
brak redundancji, jest optymalna z punktu widzenia modyfikacji
danych, zatem poyteczna dla operacji typu Rozkaz.
Natomiast posta ta w przypadku operacji typu Kwerenda
skutkuje pojawianiem si iloczynw kartezjaskich (JOIN w
SQL). Dodatkowo Agregaty mog zawiera dane zupenie nie-
istotne w kontekcie danej Kwerendy.
Stosowalno Object-relational Mapper
wiat relacyjny na obiektowy mapujemy po to, aby:
PP Pobiera w wygodny sposb obiekty biznesowe - wraz z wy-
godnymi mechanizmami typu Lazy Loading,
PP Wykonywa na nich operacje biznesowe zmieniajce ich stan
- moemy tutaj tworzy zarwno anemiczne encje modyfi-
kowane przez serwisy, jak rwnie projektowa prawdziwe
obiekty modelujce reguy i niezmienniki biznesowe (styl
Domain Driven Design),
PP Utrwala stan obiektw biznesowych - stan, ktry zmieni
si w poprzednim kroku (korzystajc z wygodnych mechani-
zmw wykrywania "brudzenia" i mechanizmu kaskadowego
zapisu caych grafw obiektw).
Jeeli stosujemy ORM (np. Java Persistence API) do tych klas
problemw, to uywamy odpowiedniego motka do odpowied-
niej klasy problemu. Czyli pobieramy kilka obiektw bizneso-
wych (Agregatw), zmieniamy jego stan, zapisujemy go.
Piszc zmieniam stan, nie mam na myli "edytuj, podpina-
jc pod formularz". Mam na myli logik aplikacji (modelujc
Use Case/User Story), ktra modyfikuje mj obiekt biznesowy
(uruchamiajc jego metody biznesowe lub settery, jeeli jest
on anemiczny). Na Listingu 1 widzimy przykad z poprzedniej
czci serii przypomnijmy: Order i Invoice to persystentne
Agregaty:
Listing 1. Serwis Aplikacyjny pl.com.bottega.erp.sales.
application.services.Purchase Service operujcy na kilku
persystentnych Agregatach
public class PurchaseService{
//...
public void approveOrder(Long orderId) {
Order order = orderRepository.load(orderId);
//sample: Specification Design Pattern
Specification<Order> orderSpecification =
generateSpecification(systemUser);
if (!orderSpecification.isSatisfiedBy(order))
throw new OrderOperationException("Order does not
meet specification", order.getEntityId());
order.submit();
Invoice invoice = invoicingService.issuance(order,
generateTaxPolicy(systemUser));
invoiceRepository.save(invoice);
orderRepository.save(order);
}
} np. na potrzeby prezentacji.
DOMAIN DRIVEN DESIGN KROK PO KROKU
Jeeli natomiast chcemy wywietli na ekranie dane, np.
dane przekrojowe w postaci tabelki (wszyscy wiemy, e dla
przestawia kolejno ich kolumn), to narzdzie typu ORM nie
jest najlepszym rozwizaniem tego problemu. W tym wypadku
na kadym etapie postpujemy nieracjonalnie:
PP Pobieramy z ORM list obiektw (zamapowanych na cae ta-
belki w bazie), gdy potrzebuj na ekranie jedynie kilku ko-
lumn z kadej tabelki (dla bazy nie robi to rnicy, ale w
przypadku komunikacji sieciowej zaczniemy odczuwa skut-
ki wydajnociowe tej decyzji),
PP Mam moliwo korzystania z mechanizmu Lazy Loadingu,
ktry nie ma sensu dla operacji typu "pobierz dane do wy-
wietlenia" i prowadzi do dramatycznego problemu z wydaj-
noci N+1 Select Problem,
PP Silnik mapera wykonuje niepotrzebne operacje zwizane ze
wsparciem dla Lazy Loading i Dirty Checking, ktre nie bd
wykorzystywane,
PP Zdradzam model biznesowy warstwie prezentacji. By
moe w prostych aplikacjach z prezentacj w technologii
webowej (ta sama maszyna pobiera i prezentuje dane) nie
jest to problem - dodatkowo zyskujemy produktywno w
pracy. Ale jeeli klienty s zdalne (np. Android)? Zdradza-
nie modelu domenowego wie si z drastycznym spadkiem
bezpieczestwa (wsteczna inynieria) oraz z koniecznoci
koordynacji prac zespow pracujcych nad "klientem" i
"serwerem", i zapewnianiem kompatybilnoci starszych
wersji klientw. Co prawda jest to kwestia oczywista, ale
w materiaach ewangelizacyjnych popularnych platform
korporacyjnych mona znale nawoywanie do takich
uproszcze,
PP Pracujemy na puli pocze zestawionej w trybie READ-WRI-
TE, gdy wystarczajcy jest tryb READ wikszo baz da-
nych optymalizuje dziaanie w tym trybie.
WARSTWY S DOBRE, ALE DWA
STOSY WARSTW S JESZCZE LEPSZE
W dotychczasowych artykuach opieralimy architektur aplika-
cji na stylu warstwowym, wprowadzajc warstwy:
PP prezentacji,
PP logiki aplikacji,
PP logiki domenowej (z ew. podziaem na 4 poziomy modelu:
Capability, Operations, Policy, Decission Support),
PP Infrastruktury.
Architektura Command-query Responsibility Segregation
przedstawiona na Rysunku 1 rozdziela odpowiedzialno kodu,
na dwa wyranie stosy warstw. Stos Write zawiera opisane
powyej warstwy i obsuguje omawiane wczeniej polecenia
typu Command operacja biznesowa i zmiana stanu systemu.
Drugi stos Read jest mniej zoony i zawiera serwisy wyszu-
kujce dane.
Separacja stosw nie dotyczy jedynie kodu. Problemy wy-
dajnociowe opisane w sekcji Potrzeba separacji mog (ale
nie musz o czym w dalszej czci) wymc decyzj o rozdzia-
le modelu danych. Model odpowiedni do operacji biznesowych
zwykle nie jest odpowiedni do szybkiego serwowania danych
/www.programistamag.pl/ 67
 INYNIERIA OPROGRAMOWANIA

STOS WRITE (COMMAND)

Stos Write niejawnie omawialimy w poprzedni
czciach byy to nasze serwisy aplikacyjne. Na-
tomiast w niniejszym artykule bazujc na zaoe-
niach i wiedzy z poprzednich czci wprowadzimy
pewne rozszerzenia.
Stos Write moemy tworzy w dwch stylach:

PP klasycznym w postaci serwisw,

PP opartym na dostosowanym do architektury
klient-serwer Wzorcu Projektowym Command.

Dla projektantw posikujcych si frameworkiem

Spring (lub innym kontenerem wspierajcym Aspect
Oriented Programming) wybr stylu ma wymiar
gwnie estetyczny, poniewa przy pomocy AOP
mona osign w klasycznym podejciu wszystko
to, co oferuje podejcie oparte o styl Command.
Jeeli natomiast nie mamy dostpu do AOP, ww-
czas styl Commad daje nam znaczn przewag dziki moliwo- Rysunek 1. Architektura Command-query Responsibility Segregation dwa sto-
ci silnego odwracania kontroli co zobaczymy ju niebawem... sy warstw. Komponent Gate zosta w szczegach przedstawiony na Rysunku 2

Styl Serwisowy

Styl Serwisowy omawialimy w poprzednich czciach serii, dla
przypomnienia odsyam do Listingu 1. Transakcyjno i bez-
pieczestwo zostay wprowadzone poprzez mechanizmy AOP
dziki zastosowaniu Adnotacji interpretowanych przez Spring
Framework.
Styl Command & Command Handler
Alternatyw dla kadej z metod Serwisowych jest para: Com-
mand i Command Handler. Jak wida na Listingach 2 i 3 styl ten
polega na rozdzieleniu klasycznego Wzorca Projektowego Com-
mand na 2 klasy. Command przesyany przez Tier Kliencki
zawiera jedynie parametry dania. Natomiast odpowiadajcy
mu Command Handler zawiera logik obsugujc Command.
Dziki temu w odrnieniu od klasycznego Wzorce Command,
aplikacje klienckie nie maj dostpu do kodu logiki aplikacyjnej
ma to oczywisty wpyw na bezpieczestwo (dekompilacja) i
oglny coupling moduw.
Oglne zasady tworzenia Command Handlerw pozostaj
takie same jak tworzenia metod Serwisw Aplikacyjnych oma-
wianych w poprzednich czciach. Przedstawiony na Listingu 3
Command Handler jest odpowiednikiem Serwisu Aplikacyjnego
z Listingu 1.
Listing 2. Command pl.com.bottega.erp.sales.application.
commands.SubmitOrderCommand polecenie zatwierdzenia zam-
wienia niosce parametry z warstwy prezentacji
@SuppressWarnings("serial")
@Command(unique=true)
public class SubmitOrderCommand implements Serializable{
private final Long orderId;
public SubmitOrderCommand(Long orderId) {
this.orderId = orderId;
} polece moemy odrzuca niepodane duplikaty bez po-
public Long getOrderId() {
return orderId;
}
@Override
public boolean equals(Object obj) {
if (obj instanceof SubmitOrderCommand) {
SubmitOrderCommand command = (SubmitOrderCommand) obj;
return orderId.equals(command.orderId);
}
return false;
}
@Override
public int hashCode() {
return orderId.hashCode();
}
}
Wsplny punkt miejsce na odwracanie
kontroli
Aplikacje klienckie komunikujc si z Serwerem, wysyaj
Command na wsplny punktu dostpowy, przedstawiony na Li-
stingu 4 oraz zilustrowany na Rysunku 2.
Wsplny punkt dostpowy pozwala na wprowadzenie intere-
sujcych i poytecznych operacji dodatkowych wykonywalnych
podczas obsugi polecenia. Przykadowo:
PP Sprawdzenie, czy dany Command jest duplikatem (przyka-
dowo atak DOS) jeeli tak, to nastpuje jego odrzucenie.
Jako duplikat traktujemy Command oznaczony odpowiedni
adnotacj oraz przechowywany w rejestrze ostatnio obsugi-
wanych polece (ostatnio, czyli w czasie x milisekund lub w
obszarze x MB pamici lub w iloci x). Przykadowo dodanie
kilkakrotnie tego samego produktu do zamwienia nie b-
dzie traktowane jako duplikat (pozwlmy klientom wydawa
pienidze), ale zatwierdzenie tego samego zamwienia wi-
cej ni raz jest niepodane. Dziki mechanizmowi historii
trzeby sigania do bazy po dane biznesowe.
PP Sprawdzenie, czy dany Command jest oznaczony jako asyn-
chroniczny jeeli tak, to wwczas odkadamy jego wyko-
nanie np. do Kolejki.

68 /4 . 2012 . (4) /
 DOMAIN DRIVEN DESIGN KROK PO KROKU

Listing 3. Command pl.com.bottega.erp.sales.application.commands.handlers.SubmitOrderCommandHandler polecenie

zatwierdzenia zamwienia niosce parametry z warstwy prezentacji

@CommandHandlerAnnotation
public class SubmitOrderCommandHandler implements CommandHandler<SubmitOrderCommand, Void> {

@Inject
private OrderRepository orderRepository;

@Inject
private InvoiceRepository invoiceRepository;

@Inject
private InvoicingService invoicingService;

@Inject
private SystemUser systemUser;

@Override
public Void handle(SubmitOrderCommand command) {
Order order = orderRepository.load(command.getOrderId());

Specification<Order> orderSpecification = generateSpecification(systemUser);

if (! orderSpecification.isSatisfiedBy(order))
throw new OrderOperationException("Order does not meet specification", order.getEntityId());

//Domain logic
order.submit();
//Domain service
Invoice invoice = invoicingService.issuance(order, generateTaxPolicy(systemUser));

orderRepository.save(order);
invoiceRepository.save(invoice);

return null;
}

Listing 4. Command pl.com.bottega.cqrs.command.impl.StandardGate wsplny punkt dostpowy

@Component
public class StandardGate implements Gate {

@Inject
private RunEnvironment runEnvironment;

private GateHistory gateHistory = new GateHistory();

@Override
public Object dispatch(Object command){
if (! gateHistory.register(command)){
//TODO log.info(duplicate)
return null;//skip duplicate
}

if (isAsynchronous(command)){
//TODO add to the queue. Queue should send this command to the RunEnvironment
return null;
}

return runEnvironment.run(command);
}

private boolean isAsynchronous(Object command) {

if (! command.getClass().isAnnotationPresent(Command.class))
return false;

Command commandAnnotation = command.getClass().getAnnotation(Command.class);

return commandAnnotation.asynchronous();
}
}

Listing 5. rodowisko uruchomieniowe pl.com.bottega.cqrs.command.impl.RunEnvironment pozwalajce na wprowadzenie dodatko-

wych mechanizmw Odwracania Kontroli

@Component
public class RunEnvironment {

public interface HandlersProvider{

CommandHandler<Object, Object> getHandler(Object command);
}

@Inject
private HandlersProvider handlersProfiver;

public Object run(Object command) {
CommandHandler<Object, Object> handler = handlersProfiver.getHandler(command);
//You can add Your own capabilities here: dependency injection, security, transaction management, logging,
profiling, spying, storing commands, etc
Object result = handler.handle(command);
//You can add Your own capabilities here
return result;
}
}

/www.programistamag.pl/ 69
 INYNIERIA OPROGRAMOWANIA

Rysunek 2. Komponent Gate stanowicy wsplny punkt dostpowy obsuga Command

wysyanych z aplikacji klienckich
Transakcyjno vs wydajno

Jedn z gwnych zasad projektowania skalowalnych

systemw z wykorzystaniem DDD jest zapisywanie
podczas transakcji jednego Agregatu. Odczyta (w
celu wykonania operacji biznesowej) moemy oczy-
wicie kilka Agregatw, ale zapisa tylko jeden.
Jest to oczywicie jedynie wskazwka, ktr mo-
emy zama w uzasadnionych przypadkach, ale za-
stanwmy si nad konsekwencj jej stosowania.
Jeeli zapisujemy w jednej transakcji kilka Agrega-
tw, to nie moemy sobie pozwoli na ich utrwalanie
w osobnych bazach danych. Zakadajc oczywiie, e
transakcje rozproszone (Double Phase Commit) nie
jest tym, czego potrzebuje architekt projektujcy wy-
sokowydajny i skalowalny system.

Zdarzenia

Co zatem zrobi, jeeli musimy zapisa wicej ni je-

Przyjrzyjmy si teraz Listingowi 5, ktry przedstawia rodo-
wisko uruchomienia polecenia.
Odpowiedzialno rodowiska Uruchomieniowego jest pro-
sta: dopasowa do Command odpowiedni ComamndHandler i
wykona go.
Dziki scentralizowanemu punktowi uruchamiania logiki apli-
kacji mamy moliwo dokonania cakowitego odwrcenia kon-
troli, bez uycia kontenera typu Spring:
PP Rozpoczcie transakcji przed uruchomianiem Hadlera oraz
jej zatwierdzenie albo wycofanie w zalenoci od powodzenia
dziaania Handlera.
PP Sprawdzenie uprawnie do wykonania Handlera.
PP Wstrzyknicie zalenoci do Handlera.
PP Logowanie poczyna klientw.
PP Profilowanie dziaania systematu.
PP Zwrcenie Handlera odpowiedniego dla pracujcego w sys-
temie klienta zagadnienie wersjonowania API i systemy
wspierajce multi-tenant.
PP Dekorowanie Handlerw wzorzec Dekoratora.
den Agregat podczas obsugi Command? Jeeli wynika
to po prostu z wymaga. Rozwizaniem mog by Zdarzenia Do-
menowe, ktre omawialimy w poprzedniej czci naszej serii.
Przypomnijmy, e Agregaty emituj zdarzenia niosce informa-
cje o istotnych w cyklu ycia Agregatw wydarzeniach bizneso-
wych. Zdarzenia do tej pory stosowalimy w celu:
PP komunikacji pomidzy osobnymi Bounded Context
PP odoeniu wykonania do kolejki operacji, ktrych natychmia-
stowe wykonanie nie jest krytyczne
PP otwarciu systemu na Pluginy (ktrymi s Listenery Zdarze,
jak rwnie Polityki DDD)
Zdarzenia bd nam rwnie potrzebne, aby odwiea dane
w dane do odczytu w drugim stosie naszej Architektury CqRS.
Zdarze moemy rwnie uywa jako Behwioralnego Modelu
Danych i zastpi nimi Relacyjn Baz w Stosie Write. Zdarze-
nia mog by analizowane przez systemy CEP (Complex Events
Processing) oraz suy jako wektory uczce dla Sztucznych
Sieci Neuronowych. Ale o tym w kolejnej odsonie serii.

W sieci
PP oficjalna strona DDD: http://domaindrivendesign.org
PP wstpny artyku powicony DDD: http://bottega.com.pl/pdf/materialy/sdj-ddd.pdf
PP przykadowy projekt Java (Spring i EJB): http://code.google.com/p/ddd-cqrs-sample/
PP przykadowy projekt .NET: http://cqrssample.codeplex.com
PP Architektura CqRS http://martinfowler.com/bliki/CQRS.html
PP Architektura Porst and Adapters: http://c2.com/cgi/wiki?PortsAndAdaptersArchitecture

Sawomir Sobtka slawomir.sobotka@bottega.com.pl

Programujcy architekt aplikacji specjalizujcy si w technologiach Java i efektywnym

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

70 /4 . 2012 . (4) /