Article Domain Driven Design

Sunt 3 posibile patternuri care ofera metode de a modela domeniul aplicatiei (Domain Logic Patterns) pe care Martin Fowler le prezinta in cartea sa Patterns of Enterprise Application Architecture (P of EAA). Nu intamplator el pleaca de la domeniu in enumerarea patternutilor enterprise – practic domeniul trebuie sa reprezinte inima aplicatiei si acolo trebuie sa fie amplasat businessul aplicatiei – practic cea mai importanta parte a aplicatiei. Ele sunt dupa cum urmeaza:
Transaction Script – domeniul este alcatuit din 2-3 grupari de clase – Services (numite de unii si Managers) care ascunde logica aplicatiei si DAO care ascunde persistenta (eventual facuta cu ORM); eventual un set additional de clase de Business care ofera calculabilitate
Table Module – bazat pe RowSet modificabil – mapare componenta la tabela – specific .NET Domain Model – un domeniu bogat de obiecte care implementeaza efectiv business-ul aplicatiei si reprezinta cu adevarat inima aplicatiei

Cazul cel mai intalnit in J(2)EE este Transaction Script – se gasesc foarte multe aplicatii scrises in acest fel – aproape toate. Interfata face apeluri intr-un layer de servicii la nivelul carora se deschid tranzactii spre serverul de baze de date sau cozi de mesaje, etc. Business-ul se afla de obicei in servicii (care apeleaza clase DAO pentru persistenta) sau se mai creaza un pachet de obiecte BO care sa faca calculabilitate. Sunt foarte multe startere si exemple pe aceasta tema. Startere: Play, Roo, SpringFuse, Appfuse, (some MDA generators – Andromda, M2Spring, Sculptor) etc

Table Module se intalneste mai ales in cazul in care interfata e component based gen Swing (desktop) sau chiar JSF (Web – dar nu request/response based). Cazul in care o componenta infasoara un ResultSet care infasoara la randul lui o tabela in baza de date. ResultSet-ul este un cursor spre tabala care permite modificarea ei in runtime – daca este UPDATABLE. Si astfel de exemple se pot gasi – in general IDE-urile permit crearea de astfel de aplicatii prin drag and drop: Matisse in NetBeans (pentru Swing), JDeveloper (pentru ADF), etc. Sincer eu am experimentat acest pattern din primele zile ca dezvoltator folosind JBuilder – care avea un foarte bun system de dezvoltare pentru Swing – in care aduceai cu drag and drop componenta in fereastra. Structurile tabelare (grid) se pretau la a comunica cu o componenta nevizuala care infasura o tabela in baza de date (continea un cursor updatabil spre BD).

Cel mai rar intalnit pattern pentru a capta domeniul aplicatiei – sincer nu am avut niciodata sansa sa vad pana anul acesta o astfel de aplicatie - este Domain Model. Aici problema s-ar pune cam asa: intai construiesti un domeniu pentru aplicatia ta (un rich domain in sensul ca obiectele nu contin doar stare ci si functionalitate modeland in totalitate businessul abordat) apoi te gandesti cum ii asiguri o infrasctructura – adica aspectele tehnice vin la urma: persistenta, concurenta, securitate, tranzactionalitate, de ce nu si prezentare, etc. Nu e vorba doar de un domeniu sarac alcatuit spre exemplu prin maperi spre tabelele din baza de date – care sunt clase doar cu stare si fara functionalitati – asa cum se intampla in Transaction Script de obicei (o favoare pe care o ofera ORM-urile). Este vorba de un model complet pentru business testabil cu un framework de testare, neavand o parte de prezentare – eventual se poate folosi in faza initiala de dezvoltare o intefata de tip consola.

Teoretic (din perspective tehnologiilor existente pe piata), acesta a fost visul pentru EJB – de a feri dezvoltatorul de aspecte de infrastructura si a-l lasa se se concentreze pe business – dar tot ce s-a putut reusi cu EJB a fost sa se expuna un layer de servicii. Deci EJB-ul mai ales cum era initial cu Service Locator si fara Dependency Injection era parca facut pentru Transaction Script. Fara persistenta obiectuala cu ORM-uri (entity bean-urile initiale au fost un esec si deci initial se scria SQL native) si fara dependency injection (se punea mai mult problema pe a expune un serviciu pe care il localizai in runtime) cam greu sa te gandesti la altceva decat Transaction Script. Spring, Hibernate si mai nou EJB 3 (CDI + JPA) care le imita ofera un teren mai placut pentru o abordare a aplicatiilor la nivel tehnologic cu un domeniu bogat.

Domain Driven Design ofera o altfel de alternative dezvoltarii de aplicatii – care seamana oarecum cu ceea ce am invatat in facultate despre modelarea obiectuala dar nu coincide deloc cu ce am gasit in industrie dupa (a nu se intelege ca cred in academic). Ideea de a construe un model obiectual pentru businessul pe care il rezolvam. Aceasta problema ar fi fara iesire daca Eric Evans nu ar oferi in cartea lui o serie de patternuri pentru construirea unui astfel de domeniu – si chiar o arhitectura standard pentru o astfel de aplicatiei – si chiar o schita pentru un process de dezvoltare care impreuna diminueaza complexitatea unei astfel de abordari. Arhirtectura oferita este tot una stratificata (layered architecture) dar acomodata cu un domeniu bogat care trebuie creat initial si o infrastructura pentru el care vine ulterior.

Chiar daca pentru mine inca aceasta abordare reprezinta doar o curiozitate – sunt infectat cu stilul de programare actual din industrie bazat pe Transaction Script – trebuie sa recunosc dezavantajele abordarii curente. Surprinzator, este foarte dificila mentenanta – pentru ca logica este intradevar raspandita peste tot in aplicatie – de la prezentare pana in baza de date. Poate nu mententa in sine – pentru ca structura stratificata usureaza mentenanta. Dar cel mai sigur Transaction Script ingreuneaza intelegerea businesului abordat – direct din cod. Pentru ca, dezvoltator de Java (= total obiectual) fiind ar trebui sa fie foarte natural sa inteleg un model – care modeleaza o realitate decat un cod care este conceput sa transporte date din interfata spre baza de date si invers si amesteca businessul peste tot (ca sa nu mai spunem ca tendinta e de a-l duplica).

Pe site-un DDD exista o aplicatie demo care poate fi folosita drept model. Este unul dintre cele mai bune lucruri care se puteau face pentru a promova DDD. In fapt este prima aplicatie scrisa in acest fel pe care am gasit-o si care pentru oricine vrea sa implementeze DDD poate fi un punct de start. Foloseste framework-uri moderne pentru infrastructura (+ build). Foloseste pattern-urile din cartea lui Erik Evens. Este conform arhitecturii din carte. Procesul de dezvoltare nu este ilustrat – putem doar presupune ca s-a pornit prima oara cu un model.

Cred ca reprezinta o greseala sa abordam problema DDD partial, plecand de la un Transaction Script modificat, doar introducand diverse grupari de obiecte care par a imbogati businessul aplicatiei. O abordare radicala in modul de dezvoltare trebuie folosita pentru a face intradevar DDD. Pentru ca acum usecase-urile din cerintele utilizator se bazeaza pe descrierea interfetei si interactiunea utilizatorului cu interfata – deci accentual cade pe interfata = pornim de la interfata in dezvoltarea aplicatiei. Altii modeleaza mai intai baza de date – care releva intradevar entitatile aplicatiei - dar nu inima ei – in fapt abordeaza o simpla problema de infrastructura = persistenta. Dar ce ar fi sa pornim cu ceea ce e intradevar important – inima aplicatiei si sa o modelam obiectual. Oare suntem in stare sa facem un salt atat de mare in gandirea noastra?

PS: Cartea este a lui Eric Evans numita Domain-Driven Design: Tackling Complexity in the Heart of Software si acest articol este o censecinta a cartii.