Alte arhitecturi: plusuri și minusuri
By type, feature-based, Atomic Design, Clean/Hexagonal și monorepo.
Actualizat
Ce compari
Nu există „cea mai bună” arhitectură — există cea potrivită pentru mărimea proiectului, echipă și cât de complex e domeniul. Mai jos, cele mai folosite variante în frontend, cu plusuri, minusuri și când le alegi.
1. Pe tip de fișier (by type)
src/components/ src/hooks/ src/utils/ src/services/ src/types/
+ zero curbă de învățare, perfect pentru proiecte mici / prototipuri. − la 100+ fișiere devine o „ladă de vechituri”; un feature e împrăștiat în 5 foldere; nicio regulă de dependențe.
Când: landing page, proiect personal, < ~30 componente.
2. Pe feature / module (Bulletproof React)
src/features/
auth/ components/ api/ hooks/ types/
cart/ components/ api/ hooks/ types/
src/components/ (shared)
+ coeziune mare, ușor de înțeles, scalează bine; regulă simplă: feature-urile nu se importă între ele. − mai puține reguli decât FSD → „unde pun codul folosit de 2 feature-uri?” rămâne la latitudinea echipei.
Când: majoritatea aplicațiilor medii. E cea mai populară alternativă la FSD.
3. Atomic Design
atoms/ (Button, Input) → molecules/ (SearchField) → organisms/ (Header) → templates/ → pages/
+ excelent pentru design system / UI kit; vocabular comun cu designerii. − organizează doar UI-ul, nu și logica sau datele; granița molecule/organism e subiectivă.
Când: librării de componente, Storybook. Poate trăi în shared/ui dintr-o altă arhitectură.
4. Clean / Hexagonal (Ports & Adapters)
domain/ entități + reguli pure, fără framework
application/ use-case-uri (createOrder)
infrastructure/ DB, API, implementări concrete
ui/ React
+ logica de business e complet independentă de framework → testabilă, portabilă. − mult boilerplate (interfețe, adaptoare); în frontend e adesea over-engineering.
Când: domeniu complex (fintech, ERP), logică partajată între web/mobile/backend.
5. Monorepo (Turborepo / Nx)
apps/web apps/admin apps/mobile
packages/ui packages/config packages/db
Nu e o alternativă, e un nivel deasupra: mai multe aplicații care partajează pachete. Fiecare app își alege arhitectura internă (des: FSD sau feature-based).
+ cod partajat real, build-uri cache-uite. − complexitate de tooling.
Comparație rapidă
| Mărime proiect | Reguli | Curbă | Logică business | |
|---|---|---|---|---|
| By type | mic | puține | ușoară | împrăștiată |
| Feature-based | mediu–mare | medii | ușoară | pe feature |
| FSD | mediu–mare | stricte | medie | entities/features |
| Atomic | UI kit | doar UI | ușoară | — |
| Clean/Hexagonal | mare, complex | stricte | grea | domain izolat |
Cum alegi
- Proiect mic sau prototip → by type, mută-te mai târziu.
- App de produs, echipă mică → feature-based.
- App care va crește, mai mulți devi, vrei reguli impuse de tooling → FSD.
- Design system → atomic în interiorul
shared/ui. - Domeniu foarte complex → idei din clean architecture (logică pură separată), nu neapărat tot ritualul.
Cea mai proastă arhitectură e cea aplicată inconsecvent. Alege una, scrie regulile în README și impune-le cu lint.
Pe scurt
- By type pentru proiecte mici; feature-based pentru majoritatea aplicațiilor; FSD când vrei reguli stricte.
- Atomic Design pentru UI kit; Clean Architecture pentru domenii complexe; monorepo pentru mai multe aplicații.
- Alege una, documenteaz-o, impune-o cu lint.