L'architettura che tutti usano senza saperlo
Se hai scritto un'applicazione PHP con controller, service e model, hai usato un'architettura a strati. La Layered Architecture (o N-Tier) e il pattern architetturale più diffuso e più antico: organizza il codice in strati orizzontali dove ogni strato ha una responsabilità specifica e comunica solo con lo strato immediatamente inferiore.
La sua forza e la semplicità concettuale: chiunque capisce che la presentazione sta sopra, la logica nel mezzo e i dati sotto. Questa intuitivita spiega perché ogni framework PHP — Laravel, Symfony, CakePHP, Soft PHP MVC — adotta implicitamente questa struttura.
I quattro strati classici
1. Presentation Layer
Gestisce l'interazione con l'utente: controller HTTP, template engine, serializzazione JSON, CLI commands. Riceve input, lo valida sintatticamente, delega allo strato inferiore, formatta la risposta. Non contiene logica di business.
2. Application Layer (Service Layer)
Orchestrazione: coordina le operazioni di business, gestisce le transazioni, applica le regole specifiche dell'applicazione. E lo strato che distingue un'applicazione web da un'app mobile che usa lo stesso dominio.
3. Domain Layer (Business Logic)
Il cuore: entita, value objects, regole di business, validazione di dominio. Indipendente da come i dati vengono presentati o persistiti. Un Order sa calcolare il totale e verificare se può essere cancellato, indipendentemente dal fatto che sia mostrato in HTML o JSON.
4. Infrastructure Layer (Data Access)
Accesso ai dati e servizi esterni: database, file system, API esterne, email, cache. Repository, ORM, client HTTP vivono qui.
La regola di dipendenza
La regola fondamentale: ogni strato dipende solo dallo strato immediatamente inferiore. La Presentation dipende dall'Application, l'Application dal Domain, il Domain dall'Infrastructure. Mai il contrario. Mai salti di strato (la Presentation non chiama direttamente l'Infrastructure).
Questa regola in pratica significa: un Controller importa un Service, mai un Repository direttamente. Un Service importa un Repository, mai un Controller. Un Repository non sa che esistono Controller e Service.
Layered Architecture in Soft PHP MVC
Presentation:app/Controllers/+views/— Controller ricevono la request e delegano
Application:app/Services/— Service orchestrano la logica
Domain:app/Model/— Model con le regole di business
Infrastructure:app/Core/DataLayer/— ORM, QueryBuilder, Database driver
Vantaggi
Semplicità: la struttura e intuitiva per qualsiasi sviluppatore, anche junior
Separazione delle responsabilità: ogni strato ha uno scopo chiaro
Testabilita: ogni strato e testabile isolatamente con mock dello strato inferiore
Sostituibilita: puoi cambiare l'ORM senza toccare i Service, o il template engine senza toccare i Controller
I limiti da conoscere
Rigidita verticale: una modifica che attraversa tutti gli strati (aggiungere un campo dal database alla UI) richiede di toccare 4 file in 4 directory diverse
Layer di passaggio: a volte un Service non fa nulla — chiama solo il Repository e restituisce il risultato. Questo "pass-through layer" aggiunge codice senza valore.
Accoppiamento orizzontale: dentro lo stesso strato, i componenti possono dipendere tra loro senza vincoli. Il modulo ordini e il modulo utenti possono mescolarsi nello stesso Service Layer.
Quando usare la Layered Architecture
Usa Layered per la maggior parte delle applicazioni web PHP: e il default ragionevole
Usa Layered quando il team e misto (junior e senior) e serve una struttura comprensibile a tutti
Evolvi verso Hexagonal quando gli strati non bastano e serve un isolamento più forte del dominio
Evolvi verso Vertical Slice quando la rigidita verticale diventa un problema e preferisci organizzare per feature
La Layered Architecture non e ne vecchia ne superata: e il punto di partenza corretto per la maggior parte dei progetti. Il suo valore e nella semplicità. La sua debolezza emerge solo quando la complessità del dominio o la dimensione del team richiedono strutture più sofisticate. Ma arrivarci dopo, quando serve, e meglio che partire da un'architettura complessa quando non serve.
👉 Leggi l'articolo completo su iadicola.it
SOCIAL SHARE CARD GENERATOR