Ce este Clean Architecture? Cum este structurată și cum funcționează?

Question

IT Interview Practice · Accepted Answer

## Ce este Clean Architecture?

**Clean Architecture** organizează software-ul în jurul comportamentului de business, separat de interfețe de utilizare, baze de date și framework-uri. Scopul este reducerea efectului schimbărilor tehnologice asupra regulilor importante ale aplicației.

De exemplu, „o comandă livrată nu poate fi anulată” este o regulă de business. Ea rămâne aceeași dacă utilizatorul folosește un site sau o aplicație mobilă, indiferent de tehnologia de stocare.

## Părți principale

Clean Architecture este ilustrată frecvent prin cercuri dispuse din interior spre exterior:

- **Entități:** Păstrează datele și regulile de business esențiale, precum o comandă și condițiile anulării ei.
- **Cazuri de utilizare:** Coordonează o operație concretă a aplicației, precum preluarea comenzii, solicitarea anulării și salvarea rezultatului.
- **Adaptoare de interfață:** Convertesc datele între logica de business și sistemele externe. Un controller transformă cererea HTTP în date de intrare pentru anulare; un adaptor de stocare transformă datele comenzii în interogări.
- **Framework-uri și instrumente:** Tehnologiile de la marginea exterioară, precum framework-ul web sau sistemul de baze de date.

**Regula esențială: codul interior nu trebuie să depindă de codul exterior.** Un caz de utilizare poate lucra cu o interfață de stocare a comenzilor definită în partea de business; un adaptor extern o implementează cu o tehnologie concretă.

## Exemplu: anularea unei comenzi

Când clientul cere anularea, controllerul apelează cazul de utilizare pentru anulare. Acesta preia comanda printr-o interfață de acces la date, apoi cere obiectului comandă să verifice dacă anularea este permisă.

Dacă nu a fost livrată și îndeplinește condițiile, starea comenzii devine anulată. Cazul de utilizare cere salvarea modificării, adaptorul bazei de date execută scrierea, iar controllerul returnează rezultatul clientului.

În timpul rulării, logica de business poate apela totuși un adaptor printr-o interfață conectată la pornire. Regula orientării dependențelor spre interior privește relațiile dintre componentele codului; nu înseamnă că datele sau apelurile pot circula într-o singură direcție.

## Avantaje

- **Testarea mai ușoară a regulilor:** Anulările permise și respinse pot fi testate cu date în memorie, fără pornirea unui server web sau a unei baze de date.
- **Un loc clar pentru comportamentul de business:** Regulile nu sunt împrăștiate între controllere și interogări, fiind mai ușor de citit și modificat consecvent.
- **Mai puține perturbări tehnologice:** Schimbarea bibliotecii de stocare sau a procesorului de cereri afectează în principal componentele externe dacă acele contracte de business rămân neschimbate.

## Limitări

- **Mai multe componente:** Interfețele, cazurile de utilizare și codul de conversie necesită timp pentru scriere și întreținere.
- **Granițele cer disciplină:** Dacă un caz de utilizare folosește direct tipuri specifice unui framework sau unei biblioteci de baze de date, logica de business devine din nou dependentă de tehnologia externă.

## Când este potrivită?

Clean Architecture este utilă sistemelor cu comportament de business complex, durată lungă de dezvoltare și nevoi frecvente de testare. Pentru o aplicație mică ce doar citește și scrie câteva tabele, o structură mai simplă poate fi mai ușor de folosit. Nu trebuie creat fiecare cerc sau director dacă nu ajută la separarea unor responsabilități reale.

Ce este Clean Architecture?

Părți principale

Exemplu: anularea unei comenzi

Avantaje

Limitări

Când este potrivită?

Întrebări conexe