Clean architecture: applicarla senza sovra-ingegnerizzare

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

1// ❌ Over-engineered
2interface UserRepositoryPort {
3  findById(id: string): Promise<UserDomainEntity | null>;
4}
5
6class UserDomainEntity {
7  constructor(private props: UserProps) {}
8  // ... 50 righe di getters/setters
9}
10
11// ✅ Pragmatico
12interface UserRepository {
13  findById(id: string): Promise<User | null>;
14}
15
16type 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.