Aplicațiile actuale sunt fără îndoială sofisticate și se bazează pe o multitudine de tehnologii. În calitate de programatori, noi ne concentrăm mai mult pe partea de implementare a softului, începând cu limbajul de programare, frameworkul sau toolul pe care îl vom folosi.
Acest lucru se întâmplă din cauza faptului că programatorii sunt înclinați spre rezolvarea de probleme, iar căutarea unor soluții reprezintă o parte interesantă a jobului. Cu toate acestea, un sistem care nu rezolvă nevoile de business nu este deloc util, indiferent cât de frumos arată sau cât de bine este implementat din punct de vedere arhitectural.
În cadrul ciclului de dezvoltare a unui proiect, pot exista multe impedimente care pot produce întârzieri: birocrația, obiective neclare, lipsa de resurse, etc. .
Designul unui sistem determină în mare măsură gradul de complexitate pe care îl poate atinge o aplicație. Atunci când complexitatea unui sistem este mult prea ridicată, acesta poate crea dificultăți de gestionare deoarece orice fel de schimbare sau încercare de extindere se poate transforma într-o sarcină dificilă. Un design bun creează posibilități de exploatare a unor cerințe complexe. În cele mai multe dintre cazuri, complexitatea aplicațiilor nu este de natură tehnică, ci este mai ales legată de domeniul de activitate sau de domeniul de business al utilizatorului.
Conceptul de domain-driven design (DDD) vine în întâmpinarea noastră pentru a ne plasa atenția în centrul aplicației, punând accentul pe complexitatea intrinsecă a domeniului de business. De asemenea, distingem domeniul de cod (unic pentru business) de subdomeniile care îl susțin (de obicei generice în natură, cum sunt banii sau timpul) și ne concentrăm eforturile asupra nucleului aplicației.
Premisele după care funcționează conceptul de domain-driven design sunt următoarele: fiecare aplicație software ar trebui să fie bazată pe un model, iar modelul ar trebui să fie bazat pe un domeniu și un domeniu logic în locul tehnologiilor utilizate. Concentrându-ne pe model, este mai ușor să obținem o terminologie acceptată deopotrivă de experții din domeniul de business, cât și de programatori, rupând astfel barierele de limbaj care există între ei.
Domain-driven design nu este o tehnologie sau o metodă, ci un set de reguli și priorități. Pentru a realiza o dezvoltare rapidă a aplicației folosind domain-driven design, avem de-a face cu o serie de principii de design, design patterns și best practices.
Atâta timp cât tehnologia infrastructurii este bine concepută, nu are importanță dacă designul nu cuprinde complexitatea domeniului. Un design de succes trebuie să se ocupe sistematic de acest aspect central al softului. Fiecare aplicație se referă la o activitate sau un domeniu de interes pentru utilizator. Aria din care face parte obiectul de interes al programului folosit de utilizator reprezintă domeniul aplicației. Unele domenii vizează lumea reală, de exemplu, programele pentru rezervarea de bilete aeriene implică oameni reali și aeronave reale.
De asemenea, există domenii intangibile pentru programatori, de exemplu, domeniul pentru un program de contabilitate sunt banii și finanțele. Pentru a crea un soft util pentru utilizator, un programator trebuie să acumuleze o serie de cunoștințe legate de activitatea utilizatorului, iar aceast lucru poate fi dificil din cauza complexității și volumului copleșitor de informație.
Soluția acestei probleme constă în folosirea de modele ca instrumente de acumulare de cunoștințe. Un model este o formă simplificată și structurată de informație. Un model bun dă sens informației și o concentrează asupra unei probleme. Un model de domeniu nu este o diagramă, ci ideea pe care diagrama o transmite. Un model nu este o simplă informație în capul unui specialist din domeniu, ci este o informație organizată riguros și o abstractizare selectivă a acelei informații. O diagramă poate reprezenta și comunica un model, la fel ca și codul scris cu grijă sau ca și o propoziție în engleză.
Scopul modelării domeniului nu este acela de a face un model cât mai realistic posibil. Chiar și într-un domeniu de lucruri tangibile din lumea reală, modelul nostru este o creație atrificială. În domain-driven design există trei utilizări de bază care determină alegerea unui model.
Modelul este informație organizată și selectiv abstractizată (informație "distilată"). Un model surprinde modul în care alegem să ne gândim la domeniu, pe măsură ce selectăm termeni, împărțim concepte și le conectăm între ele. Datorită faptului că dezvoltatorii de aplicații software și experții din domeniu partajează informații în același limbă, aceștia pot colabora într-un mod eficient. Legătura dintre model și implementare face ca primele versiuni ale softului să poate fi aplicate pentru a primi feedback în cadrul procesului de modelare.
Modelul este coloana vertebrală a limbajului folosit de toți membrii echipei. Datorită strânsei legături dintre model și implementare, programatorii pot discuta despre aplicație în acest limbaj, iar comunicarea dintre programatori și experții din domeniu poate fi realizată fără nevoia de traducere. Dacă limbajul este bazat pe model, abilitățile noastre lingvistice pot fi transformate în unelte pentru rafinarea modelului.
Modelul și nucleul designului se sprijină unul pe celălalt. Legătura dintre model și implementare face ca modelul să fie relevant și să asigure faptul că analiza realizată poate fi aplicată produsului final (aplicației). Contractul dintre model și implementare ajută substanțial în timpul procesului de mentenanță și dezvoltare continuă deoarece codul poate fi interpretat în baza înțelegerii modelului.
Nucleul aplicației constă în abilitatea de a rezolva probleme legate de domeniul utilizatorului. Rezolvarea problemelor unui domeniu complex reprezintă o sarcină dificilă chiar și pentru oamenii talentați și bine pregătiți. În general, modelarea problemelor de domeniu nu este o prioritate în multe proiecte. Cei mai mulți dintre programatori nu sunt interesați să acumuleze cunoștințe dintr-un domeniu anume în care lucrează, cu atât mai puțin să își extindă abilitățile de modelare a domeniului.
Pentru mulți programatori, problemele pe care le exercită abilitățile tehnice reprezintă o provocare. Lucrul în cadrul unui domeniu este dezordonat și necesită o mulțime de cunoștințe noi și complicate. Oamenii tehnici elaborează cod pentru a rezolva problemele de domeniu, iar acumularea de cunoștințe despre modelarea domeniului este lăsată altora. Însă complexitatea din centrul unei aplicații software trebuie abordată cu pricepere și rațiune.
Dezvoltatorii pe partea de domenii dețin oportunitatea de a-și cultiva skilluri foarte sofisticate de design. Dezordinea care se regăsește în majoritatea aplicațiilor software reprezintă o provocare tehnică interesantă. În multe discipline științifice, complexitatea este unul dintre cele mai interesante subiecte, deoarece cercetările încearcă să abordeze dezordinea din lumea reală. Pentru a începe o aplicație bazată pe probleme de domeniu, un programator trebuie să acumuleze cât mai repede o cantitate foarte mare de cunoștințe despre problema respectivă pentru a obține detaliile relevante.
Fiecare idee trebuie organizată una după cealalaltă, pe scurt, toate ideile acumulate trebuie să aibă sens. În acest proces, multe modele sunt încercate, respinse sau transformate. Modele care se păstrează cu succes rezultă dintr-un set de concepte abstracte care se potrivesc ca sens în toate detaliile. Acest mod de lucru a fost denumit ca "distilare" deoarece este cea mai riguroasă exprimare a ceea ce înseamnă organizarea și abstractizarea informației.
În metoda Waterfall, experții de business discută cu analiștii, care procesează informația și transmit rezultatul dezvoltatorilor de aplicații software. Această abordare eșuează din cauza lipsei de feedback. Analiștii au avut întreaga responsabilitate de a crea modelul bazat pe informațiile oferite de experții în business. Acest lucru a cauzat o lipsă de comunicare între analiști și dezvoltatori, și de aceea, oportunitățile de învățare pentru ambele părți au fost foarte scăzute.
Activitățile și regulile de business sunt la fel de esențiale în cadrul unui domeniu, ca și entitățile implicate; fiecare domeniu deține mai multe categorii cu diverse concepte. În paralel cu schimbarea modelului, programatorii refactorizează și implementarea care exprimă modelul, oferind aplicației posibilitatea de a utiliza aceste concepte. Atunci când se ating zone dincolo de entități și valori, acumularea de cunoștințe poate deveni foarte intensă date fiind inconsistențele din regulile de business.
Nucleul unui limbaj comun dintr-un proiect software este bazat pe modele de domeniu. Modelul este un set concepte care înglobează termeni și relații. Semantica limbajului este bazată pe termenii și interdependențele adaptate domeniului fiind în același timp suficient de precisă pentru dezvoltarea tehnică.
Comunicarea bazată pe modele nu este limitată la diagrame de tip Unified Modeling Language (UML), însă pentru a utiliza eficient modelul, este nevoie de un mediu comun de comunicare la toate nivelele. Acest limbaj comun ajută atât la redactarea documentelor, a diagramelor informale, cât și la îmbunătățirea comunicării prin intermediul codului și a testelor.
Experții în domeniu dețin o înțelegere limitată a limbajului tehnic folosit de către programatori și au la rândul lor un limbaj specific pentru a comunica în domeniul lor. De asemenea, dezvoltatorii de aplicații înțeleg și discută despre sistem într-o manieră descriptivă și funcțională, folosind cu totul alți termeni decât cei folosiți de către experții în domeniu. În altă ordine de idei, programatorii creează structuri abstracte care suportă un design, dar care nu sunt înțelese de către experți, cu toate că ambele tabere lucrează pe aceeași problemă.
Pe lângă diferența lingvistică, experții în domeniu descriu foarte vag cerințele pe care le au, în timp ce programatorii încearcă să înțeleagă un domeniu cu totul nou pentru ei. Într-un proiect care nu se bazează pe un limbaj comun, programatorii sunt mereu nevoiți să facă traducerile necesare pentru ca experții să înțeleagă. Experții din domeniu trebuie, de asemenea, să facă traduceri pentru programatori și alți experți din domeniu. Chiar și programatorii trebuie ca să traducă unele lucruri între ei. Un proiect este supus unor probleme foarte serioase atunci când comunicarea este una fracturată și neuniformă. În acest context, terminologia din discuțiile de zi cu zi este deconectată de terminologia din cod.
Pentru că fiecare parte a echipei folosește propriul limbaj, efortul și costul traducerii termenilor este foarte ridicat și există un foarte mare risc de neînțelegere. Un proiect are nevoie de un limbaj comun și robust. Cu efort din partea echipei, modelul de domeniu poate oferi acea coloană vertebrală a limbajului comun, pentru a conecta comunicarea la implementarea soft-ului.
Același model ar trebui să ofere posibilități de comunicare atât pentru programatori, cât și pentru experții din domeniu, pentru a avea aceeași viziune în legătură cu cerințele, dezvoltarea și planificarea funcționalităților dorite.
Pentru cele mai bune rezultate în folosirea domain-driven design, modelul trebuie folosit ca element de bază al limbajului. Fiecare echipă trebuie sa exerseze acel limbaj pentru a fi uniform folosit în diagrame, în scris, dar mai ales în vorbire.
În contrast cu un proiect în care nu sunt folosite modele de domeniu, chiar dacă proiectele mai complexe încearcă un fel de modele de domeniu, acestea nu dețin o conexiune cu modelul din cod. Acest fel de modele dezvoltate în cadrul proiectelor pot fi utile ca instrumente de cercetare, dar cu timpul pot deveni irelevante sau să producă încurcături.
Legătura dintre cod și modele poate fi ruptă în mai multe moduri, dar este, de regulă, o alegere conștientă. Multe dintre metodologiile existente se folosesc de un model de analiză, care este foarte diferit de design și de obicei dezvoltat de oameni diferiți. Acesta se numește model de analiză deoarece este produsul analizei domeniului de business cu scopul de a organiza concepte legate de business, fără a lua în considerare faptul că modelul va juca un rol important în implementare.
Constatăm că principalul scop al domain-driven design-lui este acela de a analiza și modela întreaga problemă a unui domeniu, folosind modele de domeniu. Un model de domeniu reprezintă un concept cheie a unei probleme de domeniu. În plus, DDD oferă ideea de limbaj comun, care poate fi folosit atât de către programatori, cât și de experții din domeniu.
Acest limbaj comun necesită a fi creat atunci când se lucrează cu modele de domeniu pentru a ușura munca de ambele părți. După definirea unui model de domeniu și un limbaj comun este creat, scopul DDD este de a realiza o conexiune între modelul de domeniu și cod, conexiune care va fi menținută pe întreaga durată a procesului de dezvoltare a proiectului. Dacă este folosită corespunzător, această legătură asigură un proces bun de dezvoltare, iar în momentul în care implementarea este modificată, aceste schimbări se vor reflecta și în modelul de domeniu și viceversa. Acest proces face ca proiectul să fie mereu la curent cu ultimele schimbări din cadrul dezvoltării.
Domain-driven design oferă o abordare foarte bună pentru procesul de dezvoltare de zi cu zi, deoarece oferă un set bun de reguli și procese care pot ajuta la dezvoltarea mai rapidă și menținerea mai ușoară a unei aplicații software.
de Cassian Lup
de Claudia Mihu
de Ovidiu Mățan
de Oana Călugar
