Clean Architecture: la teoria
La Clean Architecture di Uncle Bob definisce cerchi concentrici di dipendenza, dove le regole di business sono al centro, isolate dai dettagli implementativi.
Il problema: troppa astrazione
Ho visto progetti dove l'applicazione dogmatica della Clean Architecture ha portato a:
- 10+ file per una semplice CRUD
- Mapper ovunque per convertire tra layer
- Complessità accidentale che rallenta lo sviluppo
L'approccio pragmatico
1. Parti semplice
Non hai bisogno di tutti i layer dal giorno uno. Inizia con:
- Domain: Le tue entities e business logic
- Application: Use cases e orchestrazione
- Infrastructure: Database, API esterne
2. Aggiungi astrazione quando serve
Crea interfacce solo quando:
- Hai bisogno di testare in isolamento
- Potresti cambiare implementazione
- Il contratto deve essere esplicito
3. Evita mapper inutili
Se due strutture sono identiche, usa la stessa. I mapper hanno senso quando:
- Le strutture differiscono significativamente
- Vuoi nascondere dettagli di implementazione
Esempio pratico
typescript
1// ❌ Over-engineered2interface UserRepositoryPort {3 findById(id: string): Promise<UserDomainEntity | null>;4}56class UserDomainEntity {7 constructor(private props: UserProps) {}8 // ... 50 righe di getters/setters9}1011// ✅ Pragmatico12interface UserRepository {13 findById(id: string): Promise<User | null>;14}1516type User = {17 id: string;18 email: string;19 name: string;20};Conclusione
La Clean Architecture è una guida, non una legge. Usa il buon senso e adatta i principi al tuo contesto.
#backend#javascript#performance#best-practices
Condividi questo articolo: