Felii verticale în locul arhitecturii pe straturi: de ce câștigă structura pe funcționalități în 2026

Deschide un codebase enterprise din 2018 și layout-ul folderelor îți spune totul înainte să citești o linie de cod: controllers/, services/, repositories/, models/, dtos/, validators/. Pentru a atinge o singură funcționalitate, navighezi prin cinci directoare. Pentru a o înțelege, deschizi șapte fișiere. Aceasta este arhitectura pe straturi — numită și "clean architecture" sau "onion architecture" în funcție de cartea pe care echipa a citit-o — și timp de două decenii a fost default-ul pentru munca serioasă de backend.

În 2026, default-ul se schimbă. Echipele care livrează cel mai rapid își organizează codul pe funcționalitate, nu pe rol tehnic. Pattern-ul a avut câteva nume — vertical slice architecture, feature-first folders, modular monolith — și în era asistată de AI câștigă în liniște pentru că economia codului s-a schimbat.

De ce avea sens arhitectura pe straturi

Arhitectura pe straturi a optimizat pentru o problemă specifică: oameni care scriu fiecare linie de cod, și oameni care îl citesc pentru review și mentenanță. Beneficiile erau reale:

• Consistență — un UserController arată ca un OrderController; când îl știi pe unul, le știi pe toate.
• Infrastructură reutilizabilă — clasele de repository, controllerele de bază, serviciile generice puteau fi împărtășite între funcționalități.
• Testabilitate — fiecare strat făcea mock curat la stratul de dedesubt.
• Separarea preocupărilor — logica de domeniu era protejată de preocupările HTTP și de bază de date.

Costul era navigarea. Atingerea unei funcționalități însemna editarea a cinci fișiere în patru directoare. Pentru o echipă de ingineri seniori care țineau întreaga formă în cap, acel cost era tolerabil.

Ce s-a schimbat

Două lucruri au făcut vertical slices viabile, apoi preferabile.

Unu: testarea s-a ieftinit la nivelul slice-ului. Testarea de integrare cu baze de date reale (testcontainers, Postgres efemere, SQLite în memorie) a devenit suficient de rapidă încât mockarea stratului de date nu mai este default. Poți testa un slice end-to-end fără să plătești taxa de mockare a arhitecturii pe straturi.

Doi: asistența AI a schimbat ce costuri dor. Generarea codului este acum ieftină. Localizarea codului este ce domină costul fiecărei modificări. Un codebase pe straturi forțează modelul — și omul — să urmărească o funcționalitate prin cinci fișiere. Un vertical slice pune totul într-un singur folder, într-un singur context, unde modelul îl poate încărca tot și raționa despre el împreună.

Cum arată un vertical slice

Un slice pentru o funcționalitate de "quote draft" ar putea arăta astfel:

src/features/quote-draft/
├── quote-draft.types.ts       // tipuri de domeniu, value objects
├── quote-draft.schema.ts      // validare (zod sau similar)
├── quote-draft.db.ts          // acces la bază de date pentru acest slice
├── quote-draft.service.ts     // logică de business
├── quote-draft.api.ts         // handler HTTP
├── quote-draft.test.ts        // teste de integrare
└── quote-draft.ui.tsx         // componentă UI (dacă monorepo / Next.js)

Un singur folder. Un singur concept. Tot ce ai nevoie pentru a înțelege, modifica sau șterge funcționalitatea trăiește împreună. Ștergerea funcționalității este rm -rf src/features/quote-draft/ plus eliminarea unei intrări de rută.

Pentru un agent AI, aceasta este diferența între "încarcă 12K tokeni de context pentru a înțelege funcționalitatea" și "încarcă 80K tokeni incluzând infrastructură nerelevantă". Pentru un revizor uman, este diferența dintre trei fișiere într-un tab și douăsprezece fișiere în cinci tab-uri.

Ce sacrifici

Onestitatea contează aici. Vertical slices nu sunt gratuite.

• Reutilizarea cross-funcționalitate necesită intenție. Două funcționalități au amândouă nevoie de formatarea banilor? Fie duplici (fișier mic, OK), fie extragi într-un modul partajat (pas suplimentar). Cu arhitectura pe straturi, serviciul partajat era default-ul.
• Inconsistența se strecoară. Slice-ul A se autentifică cu un pattern, slice-ul B cu altul, pentru că nu există un AuthService central care să impună contractul. Mitigare: primitive partajate în src/lib sau src/core pentru preocupările cu adevărat cross-cutting (auth, logging, tracing, db client, i18n).
• Unele echipe găsesc duplicarea inconfortabilă. Trei slice-uri își definesc fiecare propria funcție formatMoney. "Poliția DRY" depune un PR de refactor. Rezistă dacă funcțiile diferă efectiv în feluri subtile (locale diferite, reguli de precizie diferite). Duplicarea care este sinceră despre faptul că nu este partajată este mai bună decât abstracția greșită.

Cum să migrezi de la straturi la slices

Nu face big-bang. Migrează o funcționalitate odată:

1. Alege o funcționalitate mică, bine înțeleasă. Una cu două endpoint-uri și un model este ideală.
2. Creează src/features/<feature-name>/ și copiază codul relevant acolo din structura stratificată existentă.
3. Actualizează importurile astfel încât restul codebase-ului să ajungă la funcționalitate printr-un singur punct de intrare (un barrel index.ts).
4. Mută testele de integrare în slice; verifică că încă trec.
5. Șterge fișierele stratificate vechi pentru acea funcționalitate.
6. Repetă pentru următoarea funcționalitate.

După trei sau patru slice-uri, echipa va avea o intuiție pentru ce aparține într-un slice versus ce aparține într-o bibliotecă partajată. Granița devine evidentă prin folosire.

Ce rămâne partajat

Vertical slices nu înseamnă că fiecare funcționalitate își deține propriul client de bază de date și framework HTTP. Preocupările cu adevărat cross-cutting rămân în src/lib/ sau src/core/:

• Primitive de persistență — clientul de bază de date, runner-ul de migrații, helperii de tranzacții
• Observabilitate — logger, tracer, emiter de metrici
• Middleware de autentificare — funcția care validează un JWT, atașează utilizatorul la cerere
• Configurare framework HTTP — gestionarea erorilor, parsarea cererilor, CORS
• Value objects cu adevărat universale — Email, MoneyAmount, Url, Iso8601Date

Tot restul trăiește în slice-ul care îl folosește.

Cum interacționează slice-urile

Două pattern-uri funcționează; un antipattern doare.

Pattern: granițe de modul tipate. Fiecare slice exportă un API mic, intenționat prin index.ts-ul său. Alte slice-uri importă doar ce este exportat. Internele slice-ului sunt private prin convenție. ESLint poate impune asta cu import/no-restricted-paths.

Pattern: cuplaj prin evenimente. Când slice-ul A vrea să reacționeze la ceva din slice-ul B (order-created → send-confirmation-email), o face printr-un event bus, nu printr-un apel direct. Slice-urile rămân decuplate; agentul nu trebuie să încarce slice-ul de email pentru a lucra la comenzi.

Antipattern: importuri profunde. import { internalHelper } from "@/features/billing/some-private-file" ajunge în interiorul altui slice. Aceasta este moartea lentă a oricărei arhitecturi de slice. Interzice-o la nivelul de lint în prima zi.

Ce înseamnă asta pentru echipele asistate de AI

Cel mai concret beneficiu apare prima dată când îi ceri unui agent să "adauge un buton de refund la pagina de detalii a comenzii". Cu slice-uri, agentul poate încărca slice-ul de comenzi — tipuri, serviciu, API, UI — într-un context coerent și să facă modificarea. Diff-ul este local. Review-ul este rapid.

Cu arhitectura pe straturi, agentul încarcă controllerul (un fișier), serviciul (altul), repository-ul (al treilea), DTO-ul (al patrulea) și regulile de validare (al cincilea). Contextul se umflă; acuratețea agentului scade. Revizorii văd un diff răspândit și au mai puțină încredere în el.

O echipă mică de trei ingineri folosind vertical slices și asistență AI livrează în mod obișnuit ce o echipă de zece persoane de acum doi ani livra cu arhitectura pe straturi. Arhitectura nu este singurul motiv — dar absența taxei de navigare se compune peste fiecare funcționalitate, fiecare revizor și fiecare sesiune de agent.

Dacă baza ta de cod este încă strict stratificată, nu trebuie să o rescrii. Începe cu următoarea funcționalitate nouă. Construiește-o ca slice. Vezi cum se simte echipa. Migrarea, dacă decizi să o faci, poate dura șase luni și livra continuu — nu există un weekend de rescriere.

Alegerea arhitecturală nu este religioasă. Este economică. În 2026, când localizarea codului costă mai mult decât scrierea lui, slice-urile câștigă.