Negli ultimi anni lo sviluppo Android è entrato in una fase di maturità diversa. Non basta più scegliere un pattern o applicare un framework: l’architettura è diventata una questione di decisioni reali, prese in un contesto complesso, dove intervengono stato, gestione degli errori, modularizzazione, UI dichiarativa e logiche di dominio che devono sopravvivere al tempo, ai refactoring e ai cambiamenti tecnologici.

Gli sviluppatori senior lo sanno bene: le app che scalano non sono quelle che “seguono un pattern”, ma quelle che resistono al caos naturale della crescita.

MVVM resiste perché è semplice. Cede quando gli si chiede troppo.MVVM resiste perché è semplice. Cede quando gli si chiede troppo.

MVVM continua ad essere l’approccio più diffuso: si integra con ViewModel, cicli di vita, UI reattiva. In teoria è l’equilibrio perfetto.
In pratica, però, il ViewModel diventa spesso un contenitore di qualunque responsabilità: logica di business, chiamate di rete, accessi al database, mapping dei dati, perfino navigazione.

Il risultato è un ViewModel che non “media” più nulla, ma controlla tutto.

Gli sviluppatori più esperti lo riportano al suo ruolo essenziale: coordinare lo stato della schermata.
La logica di dominio vive altrove; i repository gestiscono i dati; i mapper trasformano i modelli; i casi d’uso orchestrano le regole.

Non è MVVM a fallire. È l’uso improprio che lo trasforma in un monolite nascosto.

Clean Architecture non è un diagramma. È la direzione delle dipendenze.

Molti progetti Android si definiscono “Clean” perché presentano la classica divisione data / domain / presentation.
Ma questa struttura, da sola, non vale nulla.

La vera differenza la fa un solo principio: il dominio non deve dipendere da nulla.
Né da Retrofit, né da Room, né da CoroutineScope, né da variabili di stato della UI.

Il dominio rappresenta ciò che cambia lentamente.
La UI, le librerie, le tecnologie rappresentano ciò che cambia rapidamente.

Chi ragiona in modo senior protegge il primo dal secondo.

La logica di business non appartiene alla UI né al ViewModel

Una delle domande più rivelatrici in un colloquio tecnico è: “Dove metti la logica di business?”.

Le risposte rivelano la maturità tecnica.
Activity e Fragment sono fuori discussione; i ViewModel sono un passo avanti, ma non la destinazione finale.

Il punto di arrivo sono i casi d’uso, classi indipendenti dall’ecosistema Android, che incapsulano un’operazione specifica: convalida, recupero dati, combinazione di sorgenti, business logic.

La UI non fa calcoli.
Il ViewModel non prende decisioni.
I casi d’uso lo fanno.

Modularizzare non è un vezzo: è una risposta al dolore

Un’app piccola vive benissimo in un modulo unico. È più veloce da prototipare, semplice da leggere, immediata.
È quando la codebase cresce che emergono gli attriti: build più lenta, accoppiamenti indesiderati, team che si sovrascrivono il codice, regressioni improvvise.

La modularizzazione diventa utile quando risolve un problema reale:
– confini più chiari;
– tempi di build più brevi;
– responsabilità separate;
– onboarding più semplice.

Modularizzare troppo presto crea confusione.
Far finta di non farlo quando serve crea caos.

Repository: il livello più frainteso di tutti

Molti repository non sono repository: sono passacarte.
Chiamano Retrofit e restituiscono il risultato.

La versione matura di questo pattern è diversa: il repository diventa un decisore.
Stabilisce quando mostrare dati in cache, quando aggiornare, come unire più fonti, come nascondere alla UI le complessità della sincronizzazione.

Il ViewModel non deve sapere da dove arrivano i dati.
Deve solo gestire lo stato.

Compose cambia tutto perché porta lo stato al centro

Compose è la più grande rivoluzione UI degli ultimi anni.
Non si aggiornano più le viste: si descrive la UI in base allo stato.

Questa trasformazione richiede un approccio architetturale nuovo:
– un’unica fonte di verità per lo stato;
– UI come funzione dello stato;
– eventi che salgono, stato che scende.

Quando uno stato è duplicato o mutabile in più punti, Compose lo rende evidente immediatamente.
Le cattive architetture diventano impossibili da nascondere.

Flow supera LiveData perché è universale, non perché è nuovo

Flow non è solo “più moderno”: è più adatto a tutto quello che sta fuori dalla UI — dominio, repository, datasource.
Si combina con le coroutine, con operatori avanzati, con pipeline di dati complesse.

La UI raccoglie i Flow quando serve, ma non è il Flow a dipendere da Android.
Questo è il vantaggio decisivo.

“ViewModel giganteschi”: riconoscere e correggere il problema

Il ViewModel tende a ingrandirsi perché è comodo.
Ragiona con coroutine, resiste alle ricreazioni, si trova al centro dell’app.

Proprio per questo è la prima vittima dell’overengineering.

Gli sviluppatori senior alleggeriscono sempre il ViewModel:
il codice che “fa troppe cose” va altrove.
Se il ViewModel sembra un backend, la sua architettura è sbagliata.

La navigazione non è solo UI. È architettura.

Nelle app piccole, la navigazione diretta va bene.
Nelle app grandi crea accoppiamenti pericolosi: la UI deve interpretare l’intento, non riceverlo già trasformato.

Eventi, coordinator, navigator: tool che separano la logica di navigazione dal resto.

L’errore più comune: copiare pattern senza capirli

Molte architetture Android falliscono non perché applicano un pattern sbagliato, ma perché applicano qualsiasi pattern senza comprenderne il senso.
Si usano casi d’uso “a vuoto”, repository che non decidono nulla, moduli che non modularizzano, dependency injection che complica invece di semplificare.

La vera architettura non impressiona.
Funziona.