Îmi aduc aminte că atunci când eram la început mereu mă întrebam cum anume ar trebui să organizez un proiect astfel încât să fie ușor de înțeles și de navigat.
Mă uitam la tutoriale, citeam articole și încercam să înțeleg cum să aplic ceea ce învățam și consideram a fi bun și în cazul meu.
Încă de pe atunci, de când aveam mai puțin de un an experiență, îmi dădeam seama că modul în care se făcuse dezvoltare pe proiectele pe care lucram nu fusese unul tocmai “ingineresc”.
Sunt sigur că e și cazul tău dacă ai lucrat vreodată pe un proiect real.
Dacă nu ai lucrat încă pe niciun proiect real de producție, urăsc să-ți stric planurile dar în general ceea ce vezi prin cursuri, tutoriale sau articole online, nu se reflectă prin proiectele companiilor decât tangențial.
În realitate, “codul curat” e un mit.
Asta nu înseamnă că noi, ca și ingineri software, nu trebuie să remarcăm problemele și să încercăm să le rezolvăm, ba din contră.
Dar am vrut doar să-ți reajustez așteptările.
Ce este arhitectura software
Arhitectura software poate însemna mai multe lucruri, dar dacă ar fi să dăm o definiție general valabilă ar fi: organizarea și interacțiunea dintre două sau mai multe componente software.
Într-un caz ideal, arhitectura ar trebui să fie cea care dictează eficiența unui sistem software, adică să obțină maximul de performanță cu minimul de resurse consumate.
Dar nu e întotdeauna doar despre asta, pentru că arhitectura, în cazul ingineriei software, poate însemna mai multe lucruri:
- Arhitectura sistemului (interacțiunea dintre componentele unui sistem)
- Arhitectura soluției (interacțiunea dintre mai multe sisteme)
Arhitectura stratificată
Unul din cele mai vechi stiluri arhitecturale, pe care o să-l vezi prin multe proiecte, într-o formă sau alta, chiar și vechi de câteva decenii, e arhitectura stratificată sau N-Tier Architecture, unde “N” este numărul de straturi ale sistemului, sau Multitier Architecture.
Astfel că poți întâlni și denumirea de 3-Tier Architecture, care e același lucru, dar denotă faptul că arhitectura sistemului respectiv conține 3 straturi (layers).
Arhitectura N-Tier încearcă separarea și izolarea diferitelor zone din aplicație, astfel încât să devină cât mai modulară posibil.
3-Tier e cam cea mai populară abordare, iar împărțirea straturilor este:
- Presentation (nivelul la care se permite interacțiunea cu sistemul)
- Business/Service (toată logica pe care sistemul o tratează)
- Persistence/Data (toate interacțiunile cu baza sau bazele de date)
Fiecare strat are un rol clar și bine delimitat față de celelalte.
De asemenea relația dintre straturi merge întotdeauna de sus în jos. Niciunul din straturi nu poate depinde de un alt strat care se află deasupra lui.
Stratul din mijloc, denumit “service”, sau “business”, sau îl vei mai vedea chiar și sub denumirea de “application” e cel mai complex, pentru că orchestrează toate constrângerile/regulile definite în sistem, și în același timp deleagă apeluri și interpretează răspunsuri ale bazei de date.
Pe lângă asta, la nivelul ăsta se implementează și funcțiile transverse ale aplicației, cum ar fi : logging, servicii de cache al datelor, securitate, autentificare etc.
Detalii de implementare
Am vorbit atât de mult de straturi, de ce există și care este rolul lor, că poate acum te întrebi: ok, dar cum sunt definite straturile astea?
Ei bine răspunsul e că depinde.
Într-un proiect .NET, de exemplu, straturile pot fi reprezentate de proiecte individuale (.csproj), cu referințe între ele.
Dar genul ăsta de arhitectură nu e folosită doar pentru proiecte .NET și ea poate fi implementată în orice fel, atâta timp cât respecți regulile de organizare și relațiile dintre straturi.
Să-ți dau un exemplu, într-o aplicație express.js, de exemplu, straturile pot fi definite ca simple foldere, pentru că în acest caz nu există conceptul de “proiect” ca în .NET.
Și chiar și în proiecte .NET, sau Java, unde există modalități de a avea “module” izolate, poți folosi tot o structură de foldere pentru a-ți defini straturile, depinde doar de preferințe dar și de dimensiunea și complexitatea aplicației tale.
Capcana începătorilor
Arhitectura N-Tier, deși una din cele mai vechi folosite de inginerii software, a ajuns și una din cele mai blamate.
Au apărut de-a lungul timpului foarte multe modele de arhitectură care promit mult mai bună scalabilitate și experiență de dezvoltare decât N-Tier.
Uite câteva exemple:
- Clean Architecture
- Vertical Slice Architecture
- Onion Architecture
- Event Driven Architecture
- Modular Monolith Architecture
Mai sunt și altele, dar cred că astea sunt o parte din cele mai cunoscute.
Fiecare din cele enumerate aici are avantajele și dezavanajele ei, dar toate sunt defapt soluții la diferite probleme văzute prin ochii celor care le-au definit.
După părerea mea, toate sunt și mai complexe de înțeles și aplicat decât arhitectura N-Tier, și de-asta, în experiența mea de aproape un deceniu în inginerie software, nu am văzut nici măcar un exemplu de astfel de arhitectură bine implementată.
De cele mai multe ori sunt doar niște tentative, duse până într-un punct în care cel care a făcut implementarea a constatat că nu-i aduce atât de multe beneficii pe cât credea, sau poate nu a înțeles până la capăt despre ce e vorba și a făcut ajustări după cum a crezut.
Rezultatul fiind un dezastru din care nu se înțelege nimic și nu ajută echipa de dezvoltare la nimic.
Ceea ce în industrie numim: “spaghetti code”.
E una din cele mai comune greșeli pe care le fac juniorii, nu doar legat de arhitecturi ci de inginerie software în general, aceea de a supracomplica ceva ce ar trebui să fie extrem de simplu.
De-asta consider că, de multe ori, pentru proiecte personale nu ai nevoie de astfel de arhitecturi complicate.
Dacă vrei o separare a modulelor în aplicație, folosește cel mult o arhitectură de tip N-Tier, dar mai important de atât e să fii organizat și consecvent în structurarea aplicațiilor tale.
Asta îți va aduce mult mai mult beneficiu decât folosirea de arhitecturi complicate, care nu fac decât să te încetinească.
Atât pentru azi, pe data viitoare.