Proiectarea unei aplicații software utilizînd arhitectura [625136]

MINISTERUL EDUCAȚIEI, CULTURII ȘI CERCETĂRII
Universitatea Tehnică a Moldovei
Facultatea Calculatoare Informatică și Microelectronică
Departamentul Ingineria Software și Automatică

Proiectarea unei aplicații software utilizînd arhitectura
hexagonală

Student: _____________ Corolețchi Octavian
TI-191M

Coordonator teză: _____________ Ciubotaru Constantin,
conferențiar universitar, dr.,
cum.

Chișinău, 2020

2 MINISTЕRUL ЕDUCАȚIЕI, CULTURII ȘI CЕRCЕTĂRII АL RЕPUBLICII
MОLDОVА
Univеrsitаtеа Tеhnică а Mоldоvеi
Fаcultаtеа Cаlculаtоаrе Infоrmаtică și Micrоеlеctrоnică
Dеpаrtаmеntul Inginеriа Sоftwаrе și Аutоmаtică

Аdmis lа susținеrе
Șеf dе dеpаrtmеnt:
_____________________________
„ ___”_____________ 2020

Proiectarea unei aplicații software utilizînd arhitectura
hexagonală

Tеză dе mаstеr

Studеnt: Corolețchi Octavian, gr.TI -191M
Cоnducătо r: Ciubotaru Constantin, conf. univ. dr. cum.
Cоnsultаn t: Cоjоcаru Svеtlаnа, lеctоr univеrsitаr

Chișinău 2020

3

Subsеmnаtul (а) Corolețchi Octavian dеclаr pе prоpriе răspundеrе, că lucrаrеа dе fаță еstе
rеzultаtul muncii mеlе, rеаlizаtă pе bаzа prоpriilоr cеrcеtări și pе bаzа infоrmаțiilоr оbținutе din sursе cаrе
аu fоst citаtе și indicаtе, cоnfоrm nоrmеlоr еticе, în nоtе și în bibliоgrаfiе. Dеclаr că lucrаrеа nu а mаi fоst
prеzеntаtă sub аcеаstă fоrmă lа nici о instituțiе dе învățământ supеriоr în vеdеrеа оbținеrii titlului dе
Mаstеr în Tehnologia Informației.

Sеmnăturа аutоrului Corolețchi

4 UNIVЕRSITАTЕА TЕHNICĂ А MОLDОVЕI
FАCULTАTЕА CАLCULАTОАRЕ, INFОRMАTICĂ ȘI MICRОЕLЕCTRОNICĂ
DЕPАRTАMЕNTUL INGINЕRIА SОFTWАRЕ ȘI АUTОMАTICĂ
PRОGRАMUL DЕ STUDII TЕHNОLОGII INFОRMАȚIОNАLЕ

AVIZ
lа tеzа dе mаstеr
Tema: Proiectarea unei aplicații software utilizînd arhitectura hexagonală
Student: [anonimizat]191M

1. Actualitatea temei: Aplicațiile sunt dezvoltate în continuu. Fiecare aplicație ajunge la un moment cînd o
modificare în viitor poate afecta o mulțime de componente, și aceasta provoacă probleme și pierdere
uluitoare de timp.
2. Caracteristica tezei de licență: Drept scop, se propune realizarea unei aplicații ce va fi modelată utilizînd
arhitectura hexagonală.
3. Analiza aplicației: Aplicația are drept scop studierea și implementarea arhitecturii hex agonale.
4. Estimarea rezultatelor obținute: Această aplicație va reprezenta în sine un sistem de plăți electornice
între participanți formînd codul cît mai structurat posibil, modular și izolat.
5. Corectitudinea materialului expus: În materialul expus au fost utilizate referințe aferente pentru crearea
aplicației propuse.
6. Calitatea materialului grafic: Proiectul este prezentat prin diagrame, figuri și interfețe ale aplicației.
7. Valoarea practică a tezei: Dezvoltarea aplicațiilor are loc într -o amploare deosebită în prezent .
8. Observații și recomandări: Cerințele față de teza de master au fost îndeplinite în totalitate. Prin urmare
observații nu sunt.
9. Caracteristica student: [anonimizat]: Student: [anonimizat], a respectat cerințele impuse și a manifestat exigență în elaborarea și
calitatea tezei de master . Din cele r elatate, urmează ca teza de master poate fi admisă spre susținere, cu nota
_______ .

Lucrarea în formă elect ronică corespunde origina lului prezentat către susținere publică.
Conducă torul tezei de master Ciubotaru Constantin, conf. univ., dr., cum.

5 Rezumat

Teza de master a fost creată cu scopul de a cerceta și implementa stilul arhitectural hexagon al pentru
o aplicație. Această arhitectură poate fi folosită de un grup mare de dezvoltatori în aplicații de proporții mari.
Astfel se poate obține o aplicație modulara, cu componente izolate, ușoare de modificat fără a provoca
impact mare asupra celorlalt e componente.
În prezent dezvoltarea aplicațiilor a luat amploare și sunt necesare de cîte mai multe sisteme pentru a
acoperi o zonă cît mai mare. Unele aplicații mari, ajung la un moment dat cînd orice schimbare ia o cantitate
mare de timp iar adăugarea de servicii noi, provoacă impact imens asupra întregului ecosistem.
Structura tezei de master cuprinde introducerea, patru capitole, concluzii generale, bibliografie din 7
surse. Structura tezei de master cuprinde cinci capitole:
a) analiza domeniului de stu diu
b) modelarea și proiectarea sistemului informațional
c) realizarea sistemului
d) documentarea produsului realizat
În primul capitol se descriu și se cercetează aspecte generale din domeniul dezvoltării aplicațiilor
software, avantaje, dezavantaje, etape de dezvoltare utilizînd arhitectura hexagonală, principii de bază.
În al doilea capitol se foloseș limbajul de modelare UML pentru a descrie structura aplicației,
elemente prezentate. Se pot observa o serie de scenarii prezente în aplicație, relațiile dintre componentele
aplicației. UML este un limbaj ce oferă o reprezentare grafică standartizată înțeleasă de toți. Se poate modela
un întreg sistem precum și componentele necesare pentru funcționarea ulterioară a aplicației propuse.
În capitolul trei sunt desc rise instrumentele folosite pe parcursul implementării arhitecturii
hexagonale . Inițial dezvoltarea aplicației a fost efectuată folosind un stil arhitectural bazat pe nivele, iar apoi
a urmat refactorizarea codului pentru a implem,enta arhitectura hexagona lă.
În capitolul patru se demonstrează eficacitatea aplicației, prezentarea use -case-urilor. Aceasta a fost
efectuată utilizînd instrumentul Postman, pentru simularea request -urilor către API, și executarea
operațiunilor necesare.
În realizarea aplicației și cercetării arhitecturii hexagonale sunt respectate standartele prevăzute și
beneficiile acestui tip de arhitectură. Astfel această lucrare are drept scop informarea ulterioară a celor din
jur, și preluarea arhitecturii hexagonale drept opțiu ne de dezvoltare a unei aplicații. Într -un final se va obține
un produs modular, puternic în timp, iar orice schimbare care poate veni pe parcursul dezvoltării aplicației,
va impacta cît mai puțin drumul dezvoltării aplicației.

6 Cuprins

Introducere…… ……………………………………………………………….. ……….. ………………………………………… 7
1 Analiza Domeniului……………………………………………………………………………………….. ………………… 9
1.1 Principiul inversării dependențelor ……… …………… ………………….. ………… ………………………………. 10
1.2 Principiul responsabilității unice ……………………………………… ………… ………….. ………………. ………12
1.3 Arhitectura bazată pe nivele…… …………………………………………….. ……….. ………………………………1 4
1.4 Arhitectura hexagonală …………………………… ……….. …………….. …………….. ……………………………. ..17
2 Proiectarea sistemului …………………………………………………………. ………………………………….. 23
2.1 Diagrame ………………………………………………………………………………………….. ……………………… ..23
3 Realizarea sistemului…………………………………………………………………………….. ………… ……………….27
3.1 Administrarea aplicației……………………………………………………………………………………. …………….29
3.2 Testarea aplicației…………………………………………………………. ………………………………………………..31
3.3 Organizarea codului………………………………………………………………………………………… ……………..33
3.4 Implementarea unui Adaptor Web ………………………………………………….. ……………….. ……………… 36
3.5 Implementarea unui Adaptor de persistență…………………………………………………………………….. …39
3.6 Sisteme similar…… …………………………………………………………………………………………………………..41
4 Documentarea proiectării realizate ………………………………………………………… ……………………….. ….44
Concluzie…………………………………………………………………………………………………………………..31

7 Introducere
Această lucrare are drept scop de a construi o aplicație software web folosind tipul de arhitectură
hexagonală. Se vor analiza avantajele și dezavantajele unui astfel tip de arhitectură. După o analiză a
arhitecturii hexagonale se vor studia alternative disponibile ș ice tip se poate implementa pentru un anumit
caz specific a aplicaț iei software. Drept limbaj de programare se va folosi Java cu un framework puternic în
dezvoltare unei aplicații web denumit Spring.
În industria Tehnologiilor Informaționale termenul de arhitectură poate definit printr -o serie de
cuvinte abstracte precum fundament al aplicației, standarte și scopuri, direcție tehnica de dezvoltare
ulterioară. Toate aceste abstractizări duc într -un final la o singură idee comună, structură a sistemului și
viziunea acestuia.
Noțiunea de arhitectură software poate fi defin ită într -un final ca arhitectura produsului software.
Luînd în considerare acest termen, întîlnim mai multe aspecte de luat în calcul pe lîngă partea software. Aici
apare un nou termen de arhitectura aplicației.
Arhitectura aplicației reprezintă o totali tate de alegeri cu care va fi construit produsul. Acestea sunt
tehnologiile ce vor fi folosite pe parcursul dezvoltării, framework -uri, librării, limbaje de programare,
interfețe de programare a aplicației, în continuare folosind termenul de API.
În cont inuare apare o noua noțiune precum arhitectură de sistem, fiind un termen mult mai complex și
abstract. Îl putem considera drept mai multe aplicații combinate care formează sistemul. Întreg sistem rulează
pe un suport hardware. Deci putem defini termenul de arhitectură de sistem totalitatea aplicațiilor software,
sisteme și hardware.
Un alt termen utilizat în combinație cu arhitectura unei aplicații software este designul aplicației.
Ambele termene au unele lucruri în comun, dar nu pot fi definite ca fiind unul și același lucru. În această
combinație de termeni, lucrul în comun este p rocesul de a lua decizii spre alegerea unei arhitecturi potrivite
sau un design care să poată fi atribuit unui specific sistem.
Diferențele principale între acești doi termeni, sunt resursele alocate pentru a lua o decizie anumită
fiind ea de tip arhitect ural sau de design. În acest scop o decizie arhitecturală i se poate atribui aspecte mai
importante decît o decizie de design. O decizie arhitecturală poate consuma mai mult timp și programatori
alocați pentru a putea fi implementată decît una de design, a ceasta fiind întregul fundament pe care e
construit aplicația noastră.
Drept exemple pot fi identificate portarea unei aplicații de la un limbaj la altul, această schimbare
fiind atribuită unei decizii arhitecturale. Un alt exemplu ar fi o tehnologie spec ifică folosită pentru logare a
unor evenimente, aceasta atribuindu -se către o decizie de tip design. O schimbare arhitecturală ar putea lua
saptămîni întregi iar de design cîteva zile.

8 La momentul proiectării unei aplicații software se dorește să se const ruiască o arhitectură software
care pretinde a atinge scopuri precum dezvoltarea unui soft adaptiv și flexibil cu costuri de dezvoltare
minime. Odata cu dezvoltarea produsului, termenele limită și scurtăturile care intervin pe parcursul formării
aplicației fac ca aceste scopuri să fie foarte greu de păstrat și crea o asemenea arhitectură.
Una dintre cele mai simple tehnici de arhitectură este cea bazată pe nivele (vezi figura 1).

Figura 1 – Arhitectura pe nivele (reprezentare)

Aici dependențele sunt reprezentate de într -o singură direcție, pornind de la nivelul de prezentare,
nivelul de aplicație, nivelul de domeniu și ajungînd în final la nivelul de infrastructură. În capitolele
următoare se vor analiza de ce acest tip de arhitectură nu este potrivit și cum putem îmbunătăți acest tip
folosind arhitectura hexagonală.
Arhitectura hexagonală a fost documentată inițial în anul 2005 de către Alistair Cockburn, și a prins
amploare începînd cu anul 2015. Această arhitectură a venit cu intenția să permită apl icațiilor posibilitatea de
a fi în mod egal condusă de către utilizatori, programe, teste automate, scripturi și astfel să poată fi dezvoltată
și testată în izolare înafara disozitivelor și bazei de date care rulează într -un mod de timp real.
Această arhit ectură conține la baza cîteva principii fundamentale ce vor fi enumarate în capitolul 1.4
din această lucrare. Principlaul beneficiu al arhitecturii hexagonale vine contrar opusului ar stilului
arhitectural bazat pe niveluri. Aici dependențele nu sunt lini are, provenind de la niveluri superioare spre cele
inferioare, ci sunt direcționate către funcționalul de bază al aplicației, către obiectele de domeniu.
Într-un final se dorește ca aplicația software să păstreze opțiuni deschise și adaptate spre schimbă ri de
condiții și factori externi. Astfel se exclude faptul ca aplicația software să preia o greutate enormă și să fie
foarte greu de ajustat anumite aspecte în viitor. Astfel se pot exclude costuri enorme de dezvoltare a unui
produs software.

9 1 Analiza Do meniului
Arhitectura software deține un rol foarte important în producerea sistemelor software de succes.
Avînd un rol imens în dezvoltarea ulterioară a unui sistem software, planificarea unei arhitecturi potrivite
este neglijată de multe echipe. Datorită acestui fapt, se ajunge într -o anumita etapă a dezvoltării unui proiect
cînd se fac schimbări radicale de re -proiectare a unui sistem software datorită problemelor de performanță, a
unui cod greu de menținut pe o perioada lungă de timp.
Arhitectura softwar e se referă la structurile fundamentale ale unui sistem software și la o disciplină de
creare a unor a structuri și sisteme bine puse la punct. Fiecare structură conține elemente software. Asemenea
unui fundament de construcție, aceasta pune baza oricărei aplicație software. Este foarte important a se alege
o arhitectură potrivită la fazele de startare a unui proiect, datorită costurilor imense de schimbare odată ce au
fost deja implementate. Pentru aceasta se decurg la anumiți pași de start (vezi Figura 1. 1)

Figura 1.1 – Pașii pentru implementarea unei arhitecturi

Arhitectura software se referă la a face alegeri structurale fundamentale care sunt costisitoare să se
schimbe odată implementate. Opțiunile de arhitectură software includ opțiuni structurale s pecifice din
posibilitățile de proiectare a software -ului . De exemplu, sistemele care controlau vehiculul de lansare a

10 navetei spațiale aveau cerința de a fi foarte rapide și foarte fiabile. Prin urmare, ar trebui ales un limbaj de
calcul adecvat în timp real . În plus, pentru a satisface nevoia de fiabilitate, s -ar putea alege să aveți mai
multe copii redundante și produse independent ale programului și să rulați aceste copii pe hardware
independent în timp ce verificați rezultatele[1].
Documentarea arhi tecturii software facilitează comunicarea între părțile interesate , captează decizii
timpurii cu privire la proiectarea la nivel înalt și permite reutilizarea componentelor de proiectare între
proiecte.
Opiniile variază în ceea ce privește domeniul de apl icare al arhitecturilor software. Structura
sistemului macroscopic se referă la arhitectură ca o abstractizare la nivel superior a unui sistem software care
constă dintr -o colecție de componente de calcul împreună cu conectori care descriu interacțiunea di ntre
aceste componente. Arhitecții software ar trebui să se preocupe de acele decizii care au un impact ridicat
asupra sistemului și a părților interesate ale acestuia. Ceea ce este fundamental pentru înțelegerea unui sistem
din mediul său Deoarece proiect area arhitecturii are loc la începutul ciclului de viață al unui sistem software,
arhitectul ar trebui să se concentreze pe deciziile care de prim plan. Urmînd această linie de gândire,
problemele de proiectare arhitecturală pot deveni non -arhitecturale od ată ce ireversibilitatea lor poate fi
depășită. Arhitectura software nu ar trebui considerată doar un set de modele sau structuri, ci ar trebui să
includă deciziile care duc la aceste structuri particulare și raționamentul din spatele acestora. Această
perspectivă a condus la cercetări substanțiale în managementul cunoașterii arhitecturii software.
Sistemele software trebuie să răspundă unei varietăți de părți interesate, cum ar fi manageri de afaceri,
proprietari, utilizatori și operatori. Toate părțile i nteresate au toate preocupările lor cu privire la sistem.
Echilibrarea acestor preocupări și demonstrarea faptului că sunt abordate face parte din proiectarea
sistemului. Acest lucru implică faptul că arhitectura implică tratarea cu o mare varietate de pre ocupări și părți
interesate și are o natură multidisciplinară.

1.1 Principiul inversării dependențelor
Acest principiu spune faptul că modulele de pe nivelul ierarhic superior trebuie să fie decuplate de
cele de pe nivelurile ierarhice inferioare, această dec uplare realizându -se prin introducerea unui nivel de
abstractizare între clasele care formează nivelul ierarhic superior și cele care formează nivelurile ierarhice
inferioare. În plus principiul spune și faptul că abstractizarea nu trebuie să depindă de de talii, ci detaliile
trebuie sa depindă de abstractizare. Acest principiu este foarte important pentru reutilizarea componentelor
software. De asemenea, aplicarea corectă a acestui principiu face ca întreținerea codului să fie mult mai ușor
de realizat.

11 În Figura 1.1.1 se prezintă o diagramă de clase organizată pe trei niveluri. Astfel clasa PaymentLayer
reprezintă nivelul ierarhic superior, ea accesează funcționalitate din clasa FeeLayer aflată pe un nivel ierarhic
inferior. La rândul ei clasa FeeLayer acce sează funcționalitate din clasa UtilityLayer care de asemenea se află
pe un nivel ierarhic inferior. În concluzie, este evident faptul că în diagrama de clase prezentată nivelurile
superioare depind de nivelurile inferioare. Acest lucru înseamnă că dacă ap are o modificare la unul din
nivelurile inferioare există șanse destul de mari ca modificarea să se propage în sus spre nivelurile ierarhice
superioare. Ceea ce înseamnă că nivelurile superioare mai abstracte depind de nivelurile inferioare care sunt
mai c oncrete. Așa dar se încalcă principiul inversării dependenței.

Figura 1.1.1 – Ierarhie de clase unde nu se respectă principiul inversării dependenței

În Figura 1.1.2 se va prezenta o soluție la problema menționată mai sus în Figura 1.1.1, de această
dată se va ține cont de principiul inversării dependenței. Astfel pentru fiecare nivel care accesează o
funcționalitate dintr -un nivel ierarhic inferior se va adăuga o interfață care va fi implementată de nivelul
ierarhic inferior.
În acest scenariu interfa ța prin care comunică două niveluri diferite de clase, se va defini în nivelul
ierarhic superior, astfel încît dependența a fost inversată, și acum nivelul ierarhic inferior depinde de nivelul
ierarhic superior. S -a ajuns la o soluție în care nivelurile in ferioare nu mai afectează nivelurile superioare, ci
invers. Aceste dependețe pot fi declarate de anumite obiecte în constructor pentru a oferi o imagine foarte
clară despre ce dependențe sunt folosite și se poate asigura în momentul compilării codului desp re
disponibilitatea referințelor. În concluzie Figura 1.1.2 respectă principiul inversării dependenței. [2]

12

Figura 1.1.2 – Principiul inversării dependențelor proectat corect

1.2 Principiul responsabilității unice
Principiul Responsabilității unice (The Single Responsibility Principle) este unul dintre cele mai
cunoscute principii fiind unul din principiile SOLID. Acesta reprezintă litera “S” din această expresie. O
interpretare comună a acestui principiu este căci o componentă trebuie să execute un singur lucru predestinat,
și să-l execute corect. Acest principiu afirmă că o clasă trebuie să aibe un sing ur motiv pentru a fi modificată.
Este relativ greu de întreținut arhitectura unei aplicații. Cu cât aduci mai mulți oameni pe proiect și cu
cât investești mai mult în anumite facilități, degradarea sistemului în general se face simțită. Acest principi u
propune o strategie care forțează scrierea de obiecte simple, care au o responsabilitate exactă, ușor de urmărit
și modificat. Fiind vorba de o singură responsabilitate, probabilitatea ca schimbarea să afecteze alt cod este
destul de restrânsă. Comportam entul se va schimba evident , dar codul nu. Și în cazul unei erori, responsabilu l
e relativ ușor de identificat [ 3].
În continuare principiul va fi ilustrat printr -un exemplu. În Figura 1.2.1 este pre zentată o diagramă de
clase în care apare clasa Rectangle care are două metode: draw() și area(): double. Prima metodă este
responsabilă de desenarea formei geometrice dreptunghi pe ecran, cea de a două calculează suprafața

13 dreptunghiului. În plus clasa Re ctangle este folosită în două aplicații diferite. O aplicație face calcule
geometrice: folosește clasa Rectangle doar pentru calcule matematice și nu folosește funcționalitatea de
desenare. Cea de a două aplicație folosește atât metoda de desenare cât și c ea ce calcul al suprafeței. În acest
exemplu clasa Rectangle încalcă principiul separării responsabilităților.
Clasa are două responsabilității:
– implementează modelul matematic al for mei geometrice dreptunghi;
– desenează dreptunghiul pe o interfață grafică. [4]

Figura 1.2.1 – O singura clas ă are mai multe responsabilități

Violarea principiului separării responsabilităților în exemplul din Figura 1.2.1 duce la apariția a două
probleme. Având în vedere faptul că pentru a desena pe interfața grafică clasa Rectangle folosește clasa GUI
este evident faptul că această clasă va tr ebui să fie disponibilă și în aplicația de calcule geometrice deși
această aplicație nu folosește funcționalitatea de desenare. Acest lucru înseamnă timp de compilare mai lung
și o dimensiunea mai are a executabilului.
A doua problemă constă în faptul că, dacă clasa Rectangle este modificată pentru a rezolva o
problemă în partea de desenare acest lucru va necesita nu doar recompilarea și retestarea aplicației de
desenare ci și a celei de calcul geometric.
În continuare se va prezenta Figura 1.2.2 care va a răta un model corect a distribuire a
responasbilităților între clase.

14
Figura 1.2.2 – Distribuirea corectă a responsabilităților între clase

Astfel a fost adăugată clasa GeometricRectangle care implementează modelul matematic al unui
dreptunghi, obținând u-se astfel o decuplare a celor două responsabilități. În această nouă proiectare,
modificările făcute la partea de desenare nu mai influențează aplicația de calcule geometrice.

1.3 Arhitectura bazată pe nivele
O Arhitectură bazată pe nivele este organizarea structurii proiectului în patru categorii principale:
a) prezentare ;
b) aplicație ;
c) domeniu ;
d) infrastructură .
Fiecare dintre straturi conține obiecte legate de preocuparea specială pe care o reprezintă.
Stratul de prezentare conține toate cla sele responsabile pentru prezentarea interfeței utilizatorului
către utilizatorul final sau trimiterea răspunsului înapoi către client (în cazul în care operăm profund în back –
end).
Stratul aplicației conține toată logica cerută de aplicație pentru a înde plini cerințele sale funcționale
și, în același timp, nu face parte din regulile domeniului. În majoritatea sistemelor, stratul de aplicație const ă
în servicii care orchestrează obiectele domeniului pentru a îndeplini un scenariu de utilizare.

15 Stratul d e domeniu reprezintă domeniul subiacent, constând în principal din entități de domeniu și, în
unele cazuri, din servicii. Regulile de afaceri, cum ar fi invarianții și algoritmii, ar trebui să rămână în acest
strat.
Stratul de infrastructură (cunoscut și sub numele de stratul de persistență) conține toate clasele
responsabile de realizarea lucrurilor tehnice, cum ar fi persistarea datelor din baza de date, cum ar fi obiecte
de acces a datelor (DAO).
Există două reguli importante pentru ca o arhitectură cl asică bazată pe nivele să fie implementată
corect. Una dine ele presupune că t oate dependențele merg într -o singură direcție, de la prezentare la
infrastructură. Gestionarea persistenței și a domeniului este un pic dificil ă, deoarece stratul de infrastructură
salvează adesea obiecte de domeniu direct, deci ș tie de fapt clasele din domeniu. Cea dea două presupune că
nicio logică legată de preocuparea unui strat nu trebuie plasată într -un alt strat. De exemplu, nicio logică de
domeniu sau interogăr i de baze de date nu ar trebui f ăcute în interfața de utilizare (vezi Figura 1).
Arhitectura este un fel de termen supraîncărcat, așa că probabil ar trebui să aprofundăm ceea ce
înseamnă cu adevărat termenul în contextul straturilor . Ideea principală din s patele a rhitecturii stratificate
este o separare a preocupărilor – așa cum am spus deja, vrem să evităm amestecarea codului de domeniu sau
de bază de date cu chestii de interfață . Arhitectura stratificată nu ne spune nimic altceva despre proiectarea și
implementarea proiectului. Acest lucru implică faptul că ar trebui să -l completăm cu alte procese
arhitecturale, cum ar fi unele de proiectare inițială, sesiuni de proiectare zilnice sau chiar design complet
bazat pe domeniu. Indiferent de opțiunea pe care o alegem nu contează, cel puțin de dragul stratifică rii, dar
trebuie să se ia în considerație că a rhitectura stratificată nu ne oferă nimic în afară de un ghid despre cum să
organizăm codul sursă .
În continuare se va crea un proiect folosind IntelliJ și ar hitectura bazată pe nivele pentru a forma
structura unei aplicații sistem de plăți între beneficiari (vezi Figura 1.3.1). Acesta va fi împărțit ulterior în
pachete config, controller, domain, repository, service, security;
Pachetul config conține configu rările sistemului. Controller va fi un punct de intrare în aplicație care
va comunica cu o interfață grafică. Domain conține toate clasele ce țin de persistarea datelor. DTO
reprezintă obiectele de intrare de la interfața grafică. Repository conține între aga responsabilitate de
persistare a datelor. Service reprezintă pachetul ce răspunde de întreaga logică și reguli referitoare la sistemul
creat. Security reprezintă un pachet care va raspunde de întreaga securitate a sistemului.
Astfel aplicația devine b ine structurată și poate fi în continuare dezvoltată și extinsă. Exista și unele
dezavantaje ale acestui tip de arhitectură care se vor enumera în Figura 1.3.2.

16
Figura 1.3.1 – Structurarea unui proiect în InteliJ folosind arhitectura bazată pe nivele

17
Figura 1.3.2 – Avantaje și Dezavantaje a arhitecturii bazate pe nivele

1.4 Arhitectura hexagonală
Termenul de “arhitectură hexagonală” provine de la o documentare a lui Alistair Cockburn în 2005 și
a luat amploare din 2015. El poate fi definit drept o arhitectură software ce permite unei aplicații să devină în
mod egal condusă de către utilizatori, programe, teste automate, scripturi și să poate fi dezvoltată, testată într –
un mod izolat d e către device -uri și bază de date. Un alt beneficiu este permiterea izolării funcționalului
principal business al unei aplicații și testată automatic comportamentul acesteia independent. Acest stil de
arhitectură este pe larg utilizat în Proiectarea Condu să de Domeniu (Domain -Driven Design, DDD). Însă

18 Domain -Driven Design și arhitectura hexagonală sunt noțiuni diferite ce pot fi combinate pentru o structurare
mai bună însă aceasta nu este strict obligatoriu. Ele pot fi utilizate separat una de alta.
Arhite ctura hexagonală conține în sine trei principii de bază pe care este construită logica întregii
structurări:
a) separare explicită a interfeței utilizatorului, logica business a aplicației și partea legată de server ;
b) dependențele duc de la partea utilizatorul ui și server pînă la logica business ;
c) izolarea limitelor folosind porturi și adaptoare .
Primul principiu presupune separarea codului în trei zone largi. Acestea pot fi împărțite astfel:
a) partea utilizatorului
b) logica business
c) partea legată server
După cum se poate observa în Figura 1.4.1, în partea stîngă avem zona utilizatorului. Această parte
este responsabilă de interacțiunea aplicației cu utilizatorul sau program externe. Aceasta conține codul ce
permite această posibilitate. Deobicei acesta este format d in rute din protocolul de transfer (HTTP) pentru o
interfață de programare a aplicației (în continuare API), serializatoare JSON ale programului ce sunt
consumate de către aplicație. Deci în această zonă putem găsi actorii ce conduc aplicația, anume
funcț ionalitatea de bază business.

Figura 1.4.1 – Principiul separării codului în 3 zone

19 Partea de mijloc, denumită și zona logicii business, răspunde de izolarea codului funcționalității de
bază a aplicației. Aici se poate găsi terminologia business și o logică pură dintr -un domeniu anumit. Acesta
corespunde cu probleme concrete ce sunt rezolvate de către aplicație. În acest mod, un exper t în domeniu
cum ar fi un analist business, poate citi acest cod fără cunoștințe în programare și ne poate relata despre o
problemă de inconsistență.
În partea dreaptă a figurii 1.4.1 se poate observa partea legată de infrastructura necesară aplicației.
Ceea ce permite ca funcționalitatea propusă să lucreze. Deobicei în această zonă se găsește codul ce
comunică cu baza de d ate, folosește fișiere de sistem s -au cod ce interacționează cu alte aplicații folosint
protocolul de transfer HTTP de exemplu. Zona server găzduiește actorii ce sunt conduși de către logica
business.
Importanța acestei structurări ne permite să rezolvăm p roblemele separat. În orice bucată de timp,
putem să alegem pe ce logică putem să ne focusăm. Fiecare dintre ele se poate dezvolta interdependent de
celelalte doua din ele. Astfel ele pot spori înțelesul fără să le amestecăm, iar impactul modificării uneia dintre
ele este minor. În acest caz, sporește lucrul paralel ce se poate efectua asupra unei aplicații de rang înalt, unde
pot dezvolta zeci de persoane în același moment.
O altă caracteristică este căci noi punem codul ce răspunde de logic business în fa ța tuturor. Acesta
poate fi izolat într -o directorie aparte, sau un modul caracteristic explicit către toț i dezvoltatorii. Avantajul
principal către unei astfel de arhitecturi este faptul căci acesta poate fi definit, construit și testat fără a se lua
în considerație despre încărcarea întregului context al programului.

Figura 3.1.2 – Principiul ce prespune direcția dependențelor

20 Principiul al doilea presupune căci dependențele direcționează către centrul logic al aplicației (vezi
Figura 3.1.2) . Aici se efectuează use -case-urile necesare funcționalității de bază al programului. Avantajul
principal al acestui principiu presupune posibilitatea de control al logicii de bază de către AccountController
sau testele propuse. Logica business nu depinde de către p artea utilizatorului. Această dependență este
inversă, deci partea ce interacționează cu utilizatorul depinde de către logica d e bază a aplicației (vezi Figura
3.1.3). Această conexiune este posibilă datorită creării unei interfețe specifice SendMoney, car e reprezintă un
Use Case specific de transmitere a unor mijloace bănești.

Figura 3.1.3 – Interacționarea obiectelor din exterior cu logica de interior

Principiul al treilea presupune să se delimiteze limitele fie cărei zone. Zona utilizatorului va utiliza
logica de bază utilizînd o interfață, conform Figurii 3.1.4, se poate observa comunicarea zonelor externe cu
logica de bază prin interfețele SendMoney și LoadAccount.
Arhitectura hexagonală utilizează expresia de porturi și adaptoare pentru a reprezenta interacțiunea
dintre zonele externe și interne. Putem observa în Figura 3.1.3 căci în zona de interior, se află logica de bază
a aplicației. Aceasta definește porturile reprezentînd interfețele SendMoney și LoadAcc ount. Astfel multiple
adaptoare pot fi interschimbate, urmărind specificările din interfețe, definite prin port. Astfel aplicația devine
modulară, căpătînd posibilitatea de a adăuga adaptoare diverse în combinație cu porturi specifice pentru a
forma o inte racțiune.
De exemplu, putem schimba baza de date, implementînd funcționalitatea concretă a acesteia și codul
din interior a zonei logice nu va fi afectată.

21
Figura 3.1.4 – Delimitarea punctelor de intrare în logica de bază

Nomenclatura de arhitectură “hexagonală” are drept laitmotiv figura de hexagon, oferindu -ne
posibilitatea să putem plasa porturile și adaptoarele în acest context pe diagramă (vezi Figura 3.1.5) . Astfel
această arhitectură devine mai prietenoasă cînd amplasăm componentele într -o figu ra geometrică.

Figura 3.1.5 – Amplasarea elementelor într -un hexagon

22 În Figura 3.1.6 se vor determina avantajele arhitectur ii hexagonale.

Figura 3.1.6 – Avantajele Arhitecturii Hexagonale

În Figura 3.1.7 se vor determina avantajele arhitecturii hexagonale.

Figura 3.1.7 – Avantajele Arhitecturii Hexagonale

23 2 Proiectarea sistemului
Pentru modelarea unui sistem informațional, se folosest diferite limbaje. Unul dintre acestea este
UML. UML (Unified Modelling Language) reprezinta un limbaj vizual de modelare folositor în domeniul
software, dedicat construirii sistemelor complexe si realizarii documentelor de specificații, facand referire
in mare parte la vizualizarea, specificarea, construirea și documentarea sistemelor de aplicații. Prezinta si
limit ări cu privire la generarea codului și reprezinta de asemenea un mijloc bun pentru domeniul ingineriei
programării. [5]
Proiectarea și analiza programelor este scopul principal al unui limbaj de modelare. UML – este un
limbaj universal folosit de dezvoltat orii software din întreaga lume. UML reunește o serie de tehnici și
practici din domeniul ingineriei programării pentru a forma sisteme complexe. Într -un final obținem un
rezultat dorit, o expresivitate la un nivel înalt în care toți înțeleg cum lucrează s istemul, astfel realizîndu -se
arhitectura softului la faza inițială.
UML este un limbaj de modelare vizual, orientat obiect, care descrie proprietățile structurale și
dinamice ale unui sistem software. Prin sistem software se întelege o BD sau un modul de cod în general.
Spre deosebire de modelul EAE, UML este o colecție de tehnici de modelare, folosite pentru tratarea
multor aspecte ale procesului de concepere și dezvoltare a software -ului, de la proiectarea BD la
interacțiunea modulelor de cod. Acesta deține o exprimare grafică a structurii și comportamentului
software ce folosesc cu strictețe notațiile UML.
UML are capacitatea de a crea vederi diferite a unei aplicații. Colecția de vederi se numește model.
Unele tehnici de modelare sunt: diagrame de cl ase, care modelează entitățile unui sistem prin clase cu
atribute și metode . Diagramele de clasă descriu, de asemenea, asocierile dintre clase și legăturile asupra
acestora. Apoi urmează : diagrame de obiecte, diagrame "caz de utilizare", diagrame de stare , diagrame de
secvențe, diagrame de activitate, diagrame de colaborare.

2.1 Diagrame
Diagramele UML pot fi împărțite în: diagrame pentru modelarea structurii statice și diagrame
pentru modelarea comportamentului.
a) pentr u descrierea structurală:
1) diagrama de clasă;
2) diagrama de obiecte;
3) diagrama de componente;
4) diagrama de desfășurare .

24 b) pentru de scrierea comportamentală:
1) diagrama use -case;
2) diagrama de activitate ;
3) diagrama de stare ;
4) diagrama de secvență ;
5) diagrama de colaborare .

Diagramele structurale sunt utilizate pentru a construi și documenta aspectele statice ale sistemului.
Diagrama claselor (Class Diagram) – reprezintă structura fizică a claselor ident ificate în sistem.
Clasele reprezintă obiectele gestionale în sistem (realizarea acestora se vor prezenta în Capitolul 3.3
Organizarea Codului, Figura 3.3.3)
Diagrama componentelor (Component Diagram) – reprezintă o structură fizică a codului în termenii
componentelor de cod. Se folosește pentru a ilustra vederea statică de implementare a unui sistem.
Diagrama obiectelor – este asemanătoare cu diagrama claselor, dar în locul unei clase, se prezintă mai
multe instanțe ale acestei clase.
Diagrama de stare (State Diagram) – prezintă un ansamblu de stări prin care trece un obiect al clasei,
precum și etapele care cauzează modificări .
Diagramele comportamentale sunt utilizate pentru a construi și documenta aspectele dinamice ale
unui sistem. Din această categori se cunosc urmatoarele.
Diagrama cazurilor de utilizare (Use Case Diagram) – prezintă actorii externi și cazurile de utilizare
care pot apărea pe parcur sul executării programului. Aici se indică și conexiunile identificate între actori.
Diagrama de colaborare (Collaboration Diagram) – cuprinde colaborarea între obiecte. Se aseamănă
cu diagrama de secvență, însă se prezintă relațiile dintre obiecte.
Diag rama de activitate ( Activity Diagram) – este folosita atunci cînd se dorește să se descrie ce
activități sunt executate atunci cînd are loc o operație.
Diagrama de tranziție – se utilizează pentru a afișa vederea dinamică a unui sistem. Aici mesajele se
reprezintă prin săgeți și pot fi prezente etichete care specifică ordinea în care se transmit mesajele.
În continuare voi prezenta urmatoarele diagrame use -case pentru un utilizator simplu, ceea ce poate fi
vizualizat în Figura 2.1.1 și diagrama use -case pentru un utilizator înregistrat în Figura 2.1.2.

25

Figura 2.1.1 – Diagrama Use -Case pentru utilizator

Figura 2.1.2 – Diagrama Use -Case pentru utilizator înregistrat

26 În Figura 2.1.3 poate fi observată diagrama de desfășurare și legătura între componentele întregului
sistem proiectat.

Figura 2.1.3 – Diagrama de desfășurare a aplicației de plăți

În Figura 2.1.4 observăm procesul de lucru al unui API ce procesează request -urile primite la intrare.

Figura 2.1.4 – Diagrama de stare a API cent ral

27 3 Realizarea sistemului
Pentru a pune în practică utilizarea arhitecturii hexagonale, voi proiecta un sistem de plăți electronice.
Acest sistem va fi creat cu ajutorul unui framework Spring Boot scris în Java, iar întreaga structură a
proiectului va putea fi urmărit în mediul integrat de dezvoltare (IDE) IntelliJ. Structura de consumare a
mesajelor va fi efectuată cu ajutorul unui broker RabbitMq pentru crearea de cozi ce vor fi consumate de
către aplicația propusă inițial.
Spring Boot face parte din familia Spring .[6] Acesta este un framework pentru limbajul foarte
cunoscut Java. El a apărut pentru a ușura munca dezvoltatorilor în domeniul aplicațiilor web. Spring este
open -source și are o comunitate foarte mare care susțin acest framework. Comunitate a este cheia spre
dezvoltarea unor serii de proiecte care au aparut dupa aceasta.
Framework -ul Spring (Figura 3.1) este divizat în multiple module. Aplicațiile pot selecta ce module
sunt necesare pentru a rula. În inima lor stau 2 principii bine formaliza te, Inversion of Control și Dependency
Injection. Acestea sunt modele pe care se bazează întreg ecosistem Spring.
Exemple de module sunt:
– spring Data;
– spring Boot;
– spring MVC;
– spring JDBC;
– spring WebFlux și altele.

Figura 3.1 – Familia Spring și tehnologii

28 Pentru a avea grijă de toate dependențele, folosesc Maven (figura 3. 2). Acesta folosește un repozitoriu
central de păstrare a tuturor librariilor și instrumentelor de dezvoltare. Toate resursele necesare se includ într –
un fișier pom.xml care țin e cont de fiecare dependență și poate folosi orice versiune necesară.

Figura 3. 2 – Maven și Java

Pentru baza de date, voi folosi MySql. Acesta este un limbaj SQL (Structured Query Language)
server foarte rapid, robust, multi -utilizator și cu interfațare pentru foarte multe alte programe. Este unul dintre
cele mai populare limbaje de lucru cu baze de date SQL cu sursă deschisă. MySql este un sistem de
management a bazelor de date. O bază de date este o colecție structurată de date. În această b ază vom ține
toaate informațiile referitor la clienții aplicației propuse cît și tranzacțiile efectuate. Deci se vor ține o sursă
foarte importantă de informație.
MySql (vezi Figura 3.3) este un sistem de management a bazelor de date relaționale. O bază d e date
relațională stochează datele în tabele diferite de aia este mai flexibil și mai rapid, însă e nevoie de o
complexitate în crearea tabelelor în sine. Acesta constă în multiple fire de execuție pe serverul SQL și
prezintă mai multe programe client și librării, program administrative și interfețe de programare.

Figura 3.3 – Baza de date MySql

29 Arhitectura REST este cea care vor împreuna toate acest tehnologii diverse folosite. REST
(Representational State Transfer) este un stil de arhitectura pentru de zvoltarea de web servicii. El este
popular datorită simplicității acestuia și faptului că el este construit deasupra unui sistem existent de internet
HTTP ( Hypertext Transfer Protocol) pentru a -și atinge scopurile sale.
Un avantaj atunci cînd se foloseș te REST, este interacțiunea dintre servicii, care este una familiară
pentru toți. Toate folosest același protocol de comunicare HTTP. La fel și ceea ce ține de criptare. Nu se
folosesc framework -uri sau alte tehnologii, însă se bazează pe bine cunoscutele SSL (Secure Sockets Layer)
și TLS ( Transport Layer Security).
Toată această arhitectură este construită în baza unor concepte bine definite care sunt cunoscute de
întreaga comunitate de dezvoltatori. Structura arhitecturii REST este prezentată în Figura 3.4.

Figura 3.4 – Arhitectura REST

3.1 Administrarea aplicației
Git (vezi figura 3.1.1) este un sistem distribuit de controlare a versiunilor aplicațiilor. Astfel se pot
urmări schimbările ce se fac în cod, coordonarea între dezvoltatori, urmărirea de schimbări cît și istoria
precedentă. Toate aceste utilități oferă posibilitatea de a reveni la o versiune anterioară, ușurarea muncii de a
rezolva anumite erori.
Git are urmatoarele avantaje:
– compatibilitatea cu sistemele și protocoalele deja existen te;
– suport pentru dezvoltarea non -liniară;
– dezvoltare distribuită;
– dezvoltarea eficientă a proiectelor mari.

30

Figura 3.1.1 – Git

Etapele de lucru într -un repozitoriu sunt afișate în figura 3.1.2
Procesul începe cu crearea unui repozitori u pe bine cunoscutele platforme bitbucket sau github unde
mai apoi fiecare dezvoltator clona repozitoriul pe platforma lui individuală.
Fiecare dezvoltator lucrează pe branch -ul său unde v -a adăuga schimbări odata cu trecerea procesului
de dezvoltare. De obicei atunci cînd avem un cod funcționat și dorim să punem codul pe branch -ul principal,
se face un Pull Request spre master unde toți dezvoltatorii își lasă cu părerea și propun îmbunătățiri la cod.
Daca totul este în regulă, atunci se poate accepta și trimite codul pe branch -ul principal.

Figura 3.1.2 – Etapele de lucru și comenzi într -un repozitoriu

31 3.2 Testarea aplicației
Testarea aplicației este o etapă foarte importantă în dezvoltarea unui produs, proiect. Aplicația pe
parcursul dezvoltării trece prin numeroase etape:
a) specificarea cerințelor;
b) analiza;
c) proiectare;
d) implementare;
e) testare;
f) întreținere.
În specificarea cerințelor se determină ce componente va conține sistemul, tehnologiile care vor să fie
implicate de către dezvoltatori. Aici este un moment important, deoarece dacă beneficiarul nu v -a specifica
cerințe valide, atunci dezvoltatorii vor implementa ceea ce nu și -a imaginat beneficiarul.
În procesul de analiză, toate cerințele sunt revizuite, se documentează fiecare element. Se cr ează
funcții concrete a sistemului ce va fi creat.
Procesul de proiectare este mai mult la nivel tehnic. Scopul de bază este de a implementa structuri de
date eficiente, o arhitectură bine pusă la punct. De acest fapt va depinde ulterioara dezvoltare a si stemului.
Cu cît schimbările sunt efectuat mai tîrziu, cu atît costurile de producție cresc, și complexitatea schimbărilor
cresc.
Una dintre două cele mai întilnite metode de dezvoltare soft sunt waterfall și agile. Diferențele de cost
pot fi observate în Figura 3.2.1

Figura 3. 2.1 – Costul schimbărilor Waterfall și Agile

32
Implementarea depind e de celelalte etape. Cu cît proiectarea și analiza se fac mai detaliată cu atît
procesul de implementare va decurge mai repede și nu vor apărea erori sau neînțel egeri între dezvoltatori și
beneficiar. După o statistică, erorile software apar cel mai des în primele două etape, în fazele de analiză și
proiectare.
Testarea este etapa cînd se focusează asupra logicii interne a programului, cît și funcționalul extern.
Datele obținute sunt comparate și comparate cu cerințele specificate.
Odata cu momentele de prezentare a aplicației către beneficiar, apar tot mai mult modificări către
sistem, și cel mai des sunt necesare de modificat conținuturi.
Pentru testarea ba ck-end-ului se va folosi jUnit și adițional AssertJ. Modul de funcționare a acestuia
este reprezentat în figura 3. 2.2.
Junit testează bucăți mici de cod pentru funcționalul care îl oferă. Testele constă în evaluarea
diverselor situații de comportare a une i metode, în care trebuie să se execute funcționalul necesar și
parcurgerea fiecăror excepții.

Figura 3. 2.2 – Etapele de testare în J unit

33 3.3 Organizarea codului
Organizarea codului trebuie făcută cît mai transparent pentru o bună consistență între dezvoltatori.
Odată cu dezvoltarea unui proiect, vor participa diverse persoane, unii vor pleca, alții vor prelua o aplicație
deja bine organizată și într -un stadiu de d ezvoltare avansat. De astfel design patterns și stilurile arhitecturale
sunt o etapă foarte importantă în dezvoltarea unei aplicații. Acestea au apărut datorită generalizării anumitor
tehnici de organizare a codului și ușurinței de a deosebi un anumit stil după o anumită organizare. Astfel se
va transforma codul dintr -un stil arhitectural bazat pe nivele, într -o structură de arhitectură hexagonală.
Tranziția codului de început pentru aplicația propusă, avînd o structură ce poate fi observată în Figura
1.3.1, a fost construit urmărind modelul arhitecturii bazate pe nivele.
În continuare se va procesa structura pachetelor. Această structură se va prelua și folosi pentru
întregul proiect. Odată cu dezvoltarea unui număr mare de use -case-uri, proiectul crește în numărul claselor
necesare și într -un final observăm căci structura pachetelor este o fațadă ce acoperă funcționalul aplicației. În
Figura 3.3.2 se va prezenta transformarea structurii unui funcțional de transfer a unor mijloace bănești dintr –
un cont în altul.
Amplasînd elementele structurate în aplicație, se obține următoarea structură a claselor ce poate fi
observată în figura 3.3.1.

Figura 3.3.1 – Amplasarea claselor conform arhitecturii hexagonale

34
Figura 3.3. 2 – Organizarea funcționalului de transfer

Într-o astfel de organizare a codului, dependențele sunt implementări concrete ale interfețelor
SendMoneyUseCase și AccountRepositoryPort. Aceste interfețe conțin metodele necesare, iar acestea pot fi
implementat e specific în respectiv TransferService și AccountRepositoryAdapter. F olosind puterea
principiului inversării dependențelor și tehnica injectării pentru suplinirea obiectelor . Astfel
TransferController nu cunoaște despre implementarea exactă TransferServic e, iar TransferService nu

35 cunoaște despre implementarea exactă AccountRepositoryAdapter. Ele nu au o interdependență directă.
Astfel atunci cînd vine momentul de a modulariza anumite elemente, se cunoaște doar interfața ce conține în
sine metodele fără fun cțional. Astfel modulele de un nivel mai înalt nu depind de modulele de un nivel
inferior. Ambele trebuie să depindă de abstractizări.
Concluzionînd principiul Inversării Dependențelor, abstractizările nu trebuie să depindă de detalii
concrete, ci detalii le trebuie să depindă de abstractizări. Rezumînd aceste fapte succint, injectarea
dependențelor este o tehnică de implementare pentru popularea instanțelor unor variabile unei clase. Aici nu
trebuiesc confundate Injectarea Dependențelor de Inversarea acest ora. Prima este o metodă de a realiza
inversarea dependențelor.

Figura 3.3.3 – Diagrama de clase a funcționalității de transfer

36 În Figura 3.3.3 se poate observa structura claselor în parcurgerea traseului funcționalității de transfer
a unor mijloace băn ești de la un participant la altul. WebController -ul, în cazul nostru TransferController va
apela un port de intrare SendMoneyUseCase, care la rîndul său este implementat de un serviciu
TransferService. Acest serviciu apelează la rindul său un port de ieși re AccountRepositoryPort, care este
implementat de un adapter AccountRepositoryAdapter.
Atunci cînd va veni un moment dat în care se vor avea nevoie de facut anumite schimbări, de
schimbat tehnologii, se vor face în componenta specifică precum AccountRep ositoryAdapter.
TransferService nu este dependentă de ea, deci adăugînd o tehnologie noua de persistare a datelor sau
schimbării bazei de date, se va adăuga un AccountRepositoryAdapter specific, sau modificînd -ul pe cel
actual fără a provoca careva schimbă ri pe partea nucleului principal, și anume clasei TransferService. Fiecare
clasă este responsabilă de un anumit lucru, iar modificînd -o pe una, nu va provoca consecințe alteia.

3.4 Implementarea unui Adaptor Web
Majori tatea aplicațiilor de astăzi, au o interfață web – fie acesta un UI care poate interacționa cu un
browser web sau un HTTP API care poate fi folosit de către o sistemă pe care îl va apela aplicația.
În arhitectura propusă, comunicarea cu alte componente externe, se face cu ajutorul adaptoar elor. În
continuare se va prezenta un astfel de adaptor care prezintă o interfață web (vezi Figura 3.4 .1).

Figura 3.4 .1 – Realizarea unui adaptor web

37 În Figura 3.4 .1 putem observa forma generală a acestui principiu de separare a componentelor. Un
adaptor comunică cu aplicația prin anumite porturi, acestea fiind interfețele care sunt implementate de către
serviciile aplicației.
Rolul unui adaptor web este să contro leze funcționalul nucleului principal, fiind un punct de intrare în
aplicație. Acesta primeste request -uri din exterior, îl transformă într -un limbaj specific aplicației noastre.
Aceasta va procesa instrucțiunile conform request -ului primit. Tehnica prezen tată mai sus este specifică
Principiului Inversării Dependențelor în acțiune. Astfel apare întrebarea de ce să nu se reducă structura
adaptorului web la cea prezentată în figura 3.5.2, eliminînd porturile (interfețele).

Figura 3.4 .2 – Eliminarea porturil or intermediare

În cazul prezentat în Figura 3.4 .2, are loc eliminarea porturilor ce face conexiunea între controllere și
serviciu propriu zis. Astfel codul devine foarte cuplat, iar schimbăril în serviciu pot influența schimbarea
controalelor.
Motivu l principal pentru a demonstra eficacitatea porturilor, poate fi prezentat astfel. Porturile sunt
specificări abstracte ale funcționalului ce poate fi accesat din mediul extern. Astfel cu ajutorul lor, cunoaștem
exact ce comunicare are loc, fiind o informa ție valoroasă pentru oricare dezvoltator ce va continua să mențină
această aplicație, acesta avînd ocazia să lucreze cu codul de bază.

38 Un exemplu către acest use -case, poate fi o aplicație ce trimite date în timp real către un untilizator în
browser folos ind socketuri web. Aceasta poate fi executată cu ajutorului portului, în sense invers. Adaptorul
web va implementa portul, care va fi apelat de către nuc leul aplicației (vezi Figura 3.4 .3).

Figura 3.4 .3 – Prezentarea eficacității unui port

Astfel obțin em o aplicație ce va notifica activ un adaptor web, comunicarea acestor fiind printr -un
port de ieșire pentru a păstra dep endențelor în direcția corectă. Astfel se obține cazul în care un adaptor web
va fi atît un adaptor de intrare cît și de ieșire în ace lași timp. Acesta este un caz specific, în majoritatea
cazurilor se întîlnesc cazul comun în care un adaptor web are o singură responsabilitate, și anume un punct
de intrare în aplicație.
Un adaptor web are deobicei urmatoarele responsabilități:
a) maparea request -ului http în obiecte Java ;
b) operațiuni de autorizări ;
c) validarea parametrilor de intrare ;
d) translarea request -ului către use -case;

39 e) apelarea use -case;
f) translarea răspunsului aplicației în răspuns HTTP ;
g) returnarea răspunsului HTTP .
Pentru început, un adaptor web ascultă anumite request -uri ce se potrivesc anumitor criterii, așa cum
URL, method HTTP sau tipului de mesaj. Parametrii de intrare a mesajului ce corespun request -ului HTTP
trebuie deserializat în obiecte cu care putem interacționa ulterior. U n lucru comun, un adaptor web ce execută
operațiuni de autentificare și autorizare, verifică și returnează o eroare în caz de o eroare.

3.5 Implementarea unui Adaptor de persistență
Asemenea unui adaptor web, adaptorul de persistență este structural vorbin d asemănător cu un
adaptor web. Acesta ne permite să comunicăm cu o bază de date, și conține în sine funcționalul de persistare ,
conectare. Conform Figurii 3.5 .1, putem observa căci adaptorul de persistare, structural vorbind, arată
asemănător cu str ucturile prezentate anterior.

Figura 3.5 .1 – Amplasarea generala a unui adaptor de persistență

Serviciile din nucleul aplicației va utiliza porturi pentru a accesa adaptorul de persistență. Aceste
porturi vor fi implementate ulterior și specifica funcț ionalul exact de comunicare cu baza de date. În
arhitectura hexagonală, adaptorul de persistență este o componentă de ieșire deoarece aplicația apelează
această componentă, ci nu în sens opus.

40 Porturile în acest caz sunt un nivel de intermediere între ser viciile aplicației și codul ce va persista
datele. Astfel izolăm responsabilitățile fiecărei componente. Refactorizînd codul, nu va fi necesar alte
schimbări în serviciile interioare ale aplicației.
Responsabilitățile adaptorului de persistență se pot red uce la următoarele:
a) preluarea parametrilor de intrare;
b) maparea într -un format specific al bazei de dat e;
c) trimiterea către baza de date;
d) maparea operațiunilor a bazei de date într -un format specific aplicației;
e) returnarea datelor

Drept implementare a adaptorului de persistență se folosește librăria de mapare a obiectelor (ORM)
Spring Data Jpa. Aceasta va comunica cu baza de date, oferindu -ne posibilitatea să translăm operațiunile
necesare aplicației într -un limbaj pe care îl va înț elege baza de date.
În modelul aplicației prezentate, rolul principal îl are AccountRepositoryAdapter. Aici se află întreaga
logică de comunicare cu baza de date. Implementînd interfața AccountRepositoryPort și folosind principiul
inversării dependențelor, nucleul aplicației devine interdependent de orice schimbare în adaptor. Astfel se
poate refactoriza codul și mai mult, stratificînd funcționalul și folosing alt principiu al segregării interfețelor
din SOLID (ISP). Acesta presupune să împărțim o interfață mare în altele mai mici, iar funcționalul va
implementa doar interfața necesară acestuia. Astfel aplicația va cunoaște doar metodele ce le va folosi, și
nimic mai mult. Astfel adaptorul de persistență se poate transforma în ceva asemănător în Figura 3.5 .2.
Astfel implementînd o interfață mică, scăpăm de întregul funcțional cu care poate veni o interfață
mare. În acest caz se obține o modularitate în care un serviciu specific va implementa doar ceea ce va avea el
nevoie.
Avînd porturi mici ca î n Figura 3.5 .2, funcționalul devine adaptiv și flexibil. Una din consecințele
acestui principiu, este faptul căci se ajunge cazul în care se ajunge la un număr mare de porturi ce pot avea o
singură metodă. În aceste circumstanțe, pot exista un grup de operațiuni ce ape lează baza de date, dependente
una de alta. Deseori acestea se folosesc împreună, iar faptul să izolăm fiecare metodă aparte într -un port
apate devine inutil. Astfel se grupează într -o singura interfață.
Dorită izolării funcționalului și determinarea unor limite unui serviciu sau port, creștem paralelizarea
lucrului de către dezvoltatori. În acest caz se pot crea, ajusta funcțional, fără a încurca pe ceilalți, cîștigînd în
timp. Acest lucru este foarte important în cazul cînd se dezvoltă o aplicație enormă unde participă zeci de
persoane și sunt nevoiți să dezvolte funcțional fără a împiedica pe ceilalți.

41
Figura 3.5 .2 – Împărțirea în interfețe mici

3.6 Sisteme similare
Un exemplu asemănător de implementarea unui stil arhitectural hexagonal este bine cunoscuta
companie de streaming Netflix Originals (vezi F igura 3.6 .1).

Figura 3.6 .1 – Netflix

42 Odată cu creșterea și dezvoltarea companiei, ei au avut nevoia să construiască aplicații care să
permită eficiența pe tot parcursul procesului creativ. Ei s -au confruntat cu următoarea problemă. Au început
să lucreze la o nouă aplicație care traversează mai multe domenii ale companiei. Aveau nevoia să
construiască nucleul aplicației de la zero dar și de date care existau în sisteme diferite. Unele date de care
aveau ei nevoie erau date despre filme, date de producție, angajați, locații de filmare, erau distribuite în multe
servicii implementînd diverse protocoale: gRPC, JSON API, GraphQL și multe altele. Datele existente au
fost cruciale pentru comportamentul și logica de afaceri a aplicației. Aveau nevoie să se integreze foarte bine
de la început.
Una dintre primele aplicații pentru aducerea vizibilității producțiilor a fost construită ca un monolit.
Monolitul a permis dezvoltarea rapidă și schimbări în arii ne cunoscute. La un moment dat, peste 30 de
dezvoltatori lucrau la acest aspect și aveau peste 300 tabele de baze de date.
De-a lungul timpului, aplicațiile au evoluat de la o gamă largă de servicii spre a fi extrem de
specializate. Aceasta a dus la decizia de a descompune monolitul în servicii specifice. Această decizie nu a
fost orientată de probleme de performanță – ci prin stabilirea unor limite în jurul tuturor acestor domenii
diferite și permițând echipelor dedicate să dezvolte servicii specifice domeni ului în mod independent.
Ei aveau nevoie de cantități mari de date pentru noua aplicație, aceasta utilizînd arhitectura de tip
monolit. Faptul refactorizării aplicației și distrugerii monolitului era bine cunoscut de ei. Pentru început
foloseau date din monolit, dar erau gata să schimbe acele surse de date cu noi microservicii imediat ce au
intrat în mediul online.
Trebuia să se susțină capacitatea de a schimba sursele de date fără a afecta logica de afaceri , așa că se
știa că trebuie să le menținem dec uplate. A fost decis să se construiască aplicația pe baza principiilor din
spatele arhitecturii hexagonale .
Ideea Arhitecturii Hexagonale este de a pune intrări și ieșiri la marginile designului propus . Logica de
afaceri nu ar trebui să depindă dacă expu nem un REST sau un API GraphQL și nu ar trebui să depindă de
unde obținem date – o bază de date, un API de microserviciu expus prin gRPC sau REST sau doar un simplu
fișier CSV.
Modelul ne permite să izolăm logica de bază a aplicației noastre de preocupări externe. Izolarea
logicii noastre de bază înseamnă că putem schimba cu ușurință detaliile sursei de date fără un impact
semnificativ sau rescrierea codului major în baza de cod .
Unul dintre principalele avantaje pe care le -am văzut în a avea o aplicație cu limite clare este strategia
noastră de testare – majoritatea testelor noastre ne pot verifica logica de afaceri fără a se baza pe protocoale
care se pot schimba cu ușurință .

43 Valorificarea arhitecturii hexagonale, a permis tranziția întregului ecosist em urmînd cele trei concepte
principale specificate mai în sus. Astfel au ajuns la o structură asemenătoare cu cea din Figura 3.7.2.

Figura 3.6 .2 – Graficul dependenței din Arhitectura hexagonală

Nevoia de a schimba sursele de date a venit pe neaștepta te și a fost nevoia să se citească anumite
entități din monolit către noile microservicii expuse în nivelul de GraphQL. Microserviciul și monolitul er au
într-o continuă sincronizare, citind informațiile de la un serviciu și producînd aceleași rezultate.
Astfel ei au reușit să facă transferul de citire a datelor de la un JSON API la un GraphQL în doar 2
ore. Aceasta a fost posibilă doar datorită arhitecturii hexagonale. A fost evitată oricare cod specific în logica
de bază. Astfel ei au creat o sursă GraphQ L care implementa interfața de repozitoriu, folosindu -se de
abstractizări (vezi Figura 3.7.3). [7]

Figura 3.6.3 – Prezentarea abstractizării și interschimbarea de sursa de date

44 4 Documentarea proiectării realizate
Fiecare client va avea acces către aplicaț ie cu doar o înregistrare care poate fi făcută la prima
inițializare a aplicației. Odată logat, acesta va putea efectua operațiunile dorite. Acesta nu va putea folosi
aplicația pîna nu se va înregistra.
Această comunicare între user și partea de back -end a aplicației poate fi vizualizată în figura 4.1.

Figura 4.1 – Înregistrarea unui Utilizator

Proprietarul va face request către API spre http://host/api/app/user , iar în dependență de tipul request –
ului se va face operațiunea necesară.
O practică utilizată în rîndul dezvoltatorilor este să nu afișesze în link -ul API operațiunile necesare.
Toate acestea vor depinde de tipul request -ului. Acestea sunt urmatoarele:
– get;
– post;
– put;
– delete .
Fiecare tip de request se va utiliza în dependență de tipul lui. Get se va folosi pentru a extrage ceva.
Post pentru a introduce ceva in baza de date. Put pentru a efectua un modificare în baza de date. Iar delete
pentru a șterge utilizatori.

45
Pentru a model a request -uri către aplicație, se poate de folosit Postman. Pentru a putea folosi API -ul
prezentat în lucrare, clientul are nevoie să genereze un token pe care îl va folosi pentru un anumit interval de
timp. Aceasta poate fi vizualizat în Figura 4.2.

Figura 4.2 – Generare Jwt Token

Un exemplu de înregistrare a unui utilizator poate fi observat în Figura 4.3. Trimitem un request ce va
conține mesaj în format JSON (vezi Figura 4.4) și Jwt Tokenul generat mai sus.

Figura 4.3 – Înregistrarea unui partic ipant în sistemă

Figura 4.4 – Request -ul în format JSON

46 Pentru a vizualiza întregii useri în sistemă, putem verifica aceasta apelînd endpoint -ul
http://localhost:5000/payment/system/p articipant/all (vezi Figura 4.5).

Figura 4.5 – Prezentarea utilizatorilor în sistemă

Pentru alimentarea unui cont se va folosi http://localhost:5000/payment/system/transfer/private (vezi
Figura 4.6).

Figura 4.6 – Alimentarea unui cont

Pentru a transfera mijloace bănești către un alt cont, se indică direcția conturilor iar aceasta poate fi
observat în Figura 4.7 cum se execută un transfer dîn contul "c24dbd02 -b18e -427b -8a53 -5f03458b1e70"
către "9fee0fd1 -ea75 -4cfc-a13e -c1a53624795c" a sumei de 25 unități.

47
Figura 4.7 – Transfer de unități

Ajustarea balanței și a conturilor respecitve, poate fi observată în Figura 4.8.

Figura 4.8 – Ajustarea balanț elor conturilor

48 Concluzii
Lucrarea dată de master presupune proiectarea unei aplicații software folosind Arhitectura
Hexagonală. Această arhitectură vine cu o îmbunătățire către Arhitectura bazată pe nivele unde dependențele
sunt aranjate liniar de la niv elul superior către inferior.
S-a reușit să se construiască o serie de avantaje cum ar fi interdependența de servicii externe ce pot fi
folosite, se obține o modularitate asupra aplicației, creăm un mediu ușor de testat izolat, se ridică nivelul de
mentenanță, se crează o aplicație scalabilă iar codul devin decuplat. Astfel aplicația va acumula rezistență pe
parcursul creșterii codului și nu va crea probleme în dezvoltarea ulterioară a acesteia.
Odata cu avantajele găsite, s -a observat o complexitate asupra codului, a creșterii numărului de linii
de cod, se obține o dificultate la procesul de debug, obținem mai multe clase și nu este mereu potrivită pentru
toate tipurile de aplicații. O parte din dezavantaje pot fi rezolvate odată cu documentarea arhi tecturii date și a
procesului de dezvoltare. După acest proces, aplicația va putea primi toate avantajele menținute mai sus plus
o creștere a lucrului paralel ce va putea fi efectuat asupra aplicației într -un anumit interval de timp.
Odată cu trecerea timp ului, o aplicație își schimbă unele cerințe referitor la lucrul acesteia. Odată cu
unele schimbări pot apărea o serie de schimbări atît de nivel tehnic cît și business. Deaceea această
arhitectură ne permite să efectuăm schimbări asupra aplicației cu un ni vel de impact minim datorită
numărului mic de dependențe create între componente din mediul extern. Astfel se datorează separării
contextului business de cel cu care va interacționa utilizatorul și zona de infrastructură.
Însă am observat căci acest tip de arhitectură are o complexitate în a forma structura aplicației. Deci
daca vom avea o aplicație destul de simplă, acest tip de arhitectură nu este potrivit. Se va crea o complexitate
inutilă. Însă dacă aplicația noastră conține o logică destul de complicat ă, acest tip de arhitectură își deschide
potențialul său unic de a izola zona business și a putea fi ușor de menținut în timp și testat.
Drept exemplu pot veni cu compania de streaming Netflix care implementat același tip de arhitectură.
Ei au observat căc i odată cu creșterea sistemului, ei au nevoie de cîtă mai multă eficiență în întregul proces
creativ. Inițial ei au construit aplicația ca un monolit. În urma dezvoltării rapide și datorită schimbărilor care
au avut loc, s -a ajuns la un moment în care mono litul a prins amploare și a fost nevoie de facut tranziție la o
arhitectură ce ar permite schimbarea de resurse de date fără a impacta logica business. Astfel ei au construit
aplicația după principiile ce stau în spatele Arhitecturii Hexagonale.

49 Bibliografie
1. Arhitectura Soft [Resurs ă electronică ]. Regim de acces:
https://ro.qaz.wiki/wiki/Software_architecture
2. Principii S.O.L.I.D [Resurs ă electronică ]. Regim de acces:
https://muhaz.org/capitolul -concepte -i-abloane -care-au-influenat -dezvoltarea -apl.html?page=3
3. Robert Martin. Agile Software Development: Principles, Patterns, and Pra ctices. Editura Prentice
Hall. 2002
4. Proiectarea Sistemelor Software Complexe [Resurs ă electronică ]. Regim de acces:
http://www.aut.upt.ro/staff/diercan/data/PSSC/curs -03.pdf
5. UML [Resurs ă electronică ]. Regim de acces: https://www.scribd.com/document/46196747/Uml
6. Spring [Resursă electronică ] Regim de acces: https://spring.io/
7. Netflix [Res ursă electronică ] Regim de acces: https://netflixtechblog.com/ready -for-changes -with-
hexagonal -architecture -b315ec967749