--- title: "Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici" description: "Spatie laravel-event-sourcing v7 e CQRS: quando event sourcing serve davvero a una PMI per audit/NIS2 e quando un audit-chain con hash SHA-256 è la scelta giusta." canonical: "https://www.mauriziofonte.it/blog/post/laravel-event-sourcing-pmi-audit-tracciabilita-cqrs-spatie-event-projector.html" author: "Maurizio Fonte" date: "2025-03-21T11:52:27+01:00" modified: "2026-04-14T17:48:55+02:00" section: "Architettura Software" tags: ["Architettura Software", "Compliance"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [Compliance](https://www.mauriziofonte.it/blog/cat/compliance.html) # [Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici](https://www.mauriziofonte.it/blog/post/laravel-event-sourcing-pmi-audit-tracciabilita-cqrs-spatie-event-projector.html) Venerdì 21 Marzo 2025, alle 11:52 ![Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici](https://www.mauriziofonte.it/image/001600200-laravel-event-sourcing-pmi-audit-tracciabilita-cqrs-spatie-event-projector.jpg) Lo scorso autunno ho gestito una decisione architetturale che riassume il motivo per cui questo articolo esiste. Una PMI lombarda del settore biomedicale doveva aggiungere "tracciabilità completa delle modifiche" a un'applicazione Laravel di gestione dispositivi medici, requisito imposto da un audit interno di certificazione ISO 13485 e dalla Direttiva NIS2 che li riguarda direttamente come operatore sanitario. Il responsabile IT mi ha contattato dicendo "abbiamo letto di Event Sourcing, vogliamo implementarlo". Dopo un'ora di discussione, abbiamo concluso che Event Sourcing non era la risposta giusta per il loro caso. Era un'ottima risposta a una domanda diversa. La risposta giusta - un audit log immutabile basato su hash chain SHA-256 - è arrivata in 4 giorni di lavoro. La risposta sbagliata - full Event Sourcing con aggregate root, projector e command bus su 60 entità di dominio esistenti - sarebbe stata un progetto da 4 mesi e probabilmente un fallimento. Questo articolo non è "come implementare Event Sourcing in Laravel". È prima di tutto "quando ha senso per una PMI" e poi, se la risposta è sì, "come farlo bene con gli strumenti del 2026". ## Cosa risolve davvero Event Sourcing (e cosa NON risolve) Event Sourcing è un pattern architetturale che inverte la prospettiva sullo stato. Nel modello CRUD tradizionale, lo stato dell'applicazione è la verità: una riga in `orders` rappresenta l'ordine come è ora. Le modifiche sono sovrascritture, e ogni `UPDATE` cancella l'informazione precedente. Nel modello Event Sourced, lo stato è una proiezione: la verità è la sequenza immutabile di eventi (`OrderCreated`, `OrderItemAdded`, `OrderShipped`, `OrderCancelled`) e lo stato corrente si ricostruisce replicandoli. Il database non memorizza più "l'ordine adesso", memorizza "tutto quello che è successo all'ordine". Per una formalizzazione classica del concetto, [Martin Fowler ha pubblicato il pattern Event Sourcing nel 2005](https://martinfowler.com/eaaDev/EventSourcing.html) e la sua descrizione resta tutt'oggi il riferimento migliore. Questa inversione non è cosmetica. Cambia tre cose concrete: 1. **Hai un audit log nativo per costruzione.** Non c'è bisogno di un `audit_log` separato - la sequenza di eventi È l'audit log. Ogni stato passato è ricostruibile per replay. 2. **Puoi rispondere a domande temporali.** "Qual era il prezzo di questo prodotto il 15 gennaio 2026 alle 14:32?" è una query di replay, non una struttura dati che devi aver progettato in anticipo. 3. **Disaccoppi le scritture dalle letture.** Gli eventi sono il modello di scrittura, le proiezioni (tabelle ottimizzate per la query) sono il modello di lettura. Questo è il punto di contatto naturale con CQRS (Command Query Responsibility Segregation). Quello che Event Sourcing **non** risolve, e che molti articoli sbrigativi vendono come benefici: non aumenta automaticamente la performance (le proiezioni vanno mantenute, e replay di eventi su milioni di record è lento), non sostituisce il bisogno di backup, non è una garanzia di consistenza distribuita, e - questo è il punto più sottovalutato - non è amichevole con il GDPR. Il diritto all'oblio dell'art. 17 GDPR pretende la cancellazione dei dati personali, ma il modello Event Sourced si basa sull'immutabilità della storia degli eventi. Su questo torno alla fine. > Event Sourcing risponde alla domanda "perché siamo arrivati allo stato attuale?". CRUD risponde alla domanda "qual è lo stato attuale?". Sono due domande diverse, e moltissime applicazioni PMI hanno solo bisogno della seconda. ## Quando ha davvero senso per una PMI nel 2026? In dieci anni di consulenza ho visto decine di "audit trail" implementati con success e qualche tentativo fallito di Event Sourcing. La regola operativa che applico è semplice: **Event Sourcing ha senso quando il "perché" del cambiamento è una domanda business ricorrente, non quando l'audit è solo un requisito di compliance.** In concreto, lo consiglio nei seguenti casi: - **Sistemi finanziari/contabili dove ogni movimento ha valore legale.** Conti correnti, libri mastri, sistemi di fatturazione elettronica con SDI dove la sequenza degli eventi È il modello di business. La banca centrale del mio cliente più "esoterico" gira proprio su questo pattern. - **Workflow complessi dove la storia delle decisioni è oggetto di analisi.** Approvazioni multi-step, gestione richieste di rimborso, ticketing con escalation. Il "perché" l'utente è arrivato a uno stato è un dato di business. - **Sistemi che devono ricostruire stati passati per analisi.** Dispositivi IoT con telemetria storica, sistemi di trading con backtesting, applicazioni che devono rispondere a "cosa avremmo visto se avessimo guardato quel giorno?". Lo sconsiglio quando: - L'audit è un requisito di compliance ma il business non ne usa mai la storia. In questo caso un audit log immutabile semplice (vedi sezione successiva) costa il 5% dell'effort di Event Sourcing e copre lo stesso requisito. - L'applicazione è già un monolite CRUD maturo con decine di entità. Refactorare un'app Laravel di 5 anni a Event Sourcing significa riscrivere il modello di dominio, e nessun cliente PMI ha il budget per un'operazione del genere senza un payoff business chiaro. Un percorso più pragmatico è il refactoring incrementale verso [Service Layer e Repository Pattern, che ho documentato come passaggio intermedio per i Fat Controller Laravel](https://www.mauriziofonte.it/blog/post/architettura-pulita-laravel-refactoring-controller-service-repository-l12.html). - Il team non ha esperienza precedente con DDD o Event-Driven design. Event Sourcing impone una curva di apprendimento ripida, e gli errori architetturali sui primi mesi compromettono l'intero progetto. Per il caso del cliente biomedicale che raccontavo all'inizio, nessuno dei tre scenari positivi era applicabile: avevano bisogno di "chi ha modificato cosa, quando, e poter dimostrare che l'audit log non è stato manomesso". È un requisito di compliance, non di business. Vediamo cosa abbiamo fatto. ## L'alternativa pragmatica: audit-chain immutabile con hash SHA-256 Per il 70-80% dei requisiti di tracciabilità di una PMI, la soluzione corretta non è Event Sourcing ma un audit log immutabile con catena di hash crittografici. Il pattern è semplice: ogni record di audit memorizza un hash SHA-256 calcolato sui dati del record stesso più l'hash del record precedente. Se qualcuno tenta di modificare un record passato, la catena di hash si rompe e la manomissione è rilevabile per verifica matematica. Su Laravel, il pacchetto [graymatter/laravel-audit-chain](https://packagist.org/packages/graymatter/laravel-audit-chain) implementa esattamente questo pattern, ed è progettato dichiaratamente per [GDPR articoli 15, 17, 33 e NIS2 articolo 21](https://www.mauriziofonte.it/blog/post/gdpr-nis2-rischi-non-compliance-normativa.html). Offre due modalità: `HasActivityLog` (audit log "leggero" senza catena crittografica) e `HasAuditTrail` (modalità full con SHA-256 hash chain). Il codice di applicazione su un model è banale: ```php // app/Models/Device.php use GrayMatter\LaravelAuditChain\Concerns\HasAuditTrail; use GrayMatter\LaravelAuditChain\Attributes\PersonalData; class Device extends Model { use HasAuditTrail; #[PersonalData] protected $fillable = [ 'serial_number', 'patient_id', // dato personale → annotato 'last_calibration_at', 'firmware_version', ]; } ``` L'attributo `#[PersonalData]` segnala al package quali campi sono dati personali, abilitando export/anonymization conforme all'art. 15 GDPR (diritto di accesso) e all'art. 17 (diritto all'oblio) tramite redazione mirata. Gli Eloquent guard del package impediscono `update` e `delete` sui record di audit a livello applicativo, e la tabella `audit_trail` può essere protetta a livello DB con un GRANT che concede solo `INSERT` all'utente applicativo, mai `UPDATE` o `DELETE` (questa è la barriera reale). Per il cliente biomedicale, questa configurazione ha soddisfatto sia l'auditor ISO 13485 sia il DPO interno per NIS2. Quando questo NON basta, e ti serve davvero la potenza di Event Sourcing, si passa al pattern grosso. ## Spatie laravel-event-sourcing v7 con CQRS in produzione Se hai mappato il tuo dominio e hai concluso che Event Sourcing è la risposta giusta, [Spatie laravel-event-sourcing v7](https://spatie.be/docs/laravel-event-sourcing/v7/introduction) è oggi il pacchetto di riferimento per Laravel. Maintainership solida, documentazione estesa, integrato con Laravel Horizon per la coda di processing, e - feature centrale di v7 - supporto nativo a CQRS via command bus con mapping basato su PHP attribute. La novità rispetto alle versioni precedenti è che non devi più scrivere command handler manuali per i casi semplici: dichiari un'attribute `#[HandledBy]` sulla classe Command e l'aggregate root riceve il command direttamente. Esempio di un command per aggiungere un item al carrello, mappato automaticamente su `CartAggregateRoot`: ```php // app/Domain/Cart/Commands/AddCartItem.php use App\Domain\Cart\CartAggregateRoot; use Spatie\EventSourcing\Commands\Attributes\AggregateUuid; use Spatie\EventSourcing\Commands\Attributes\HandledBy; #[HandledBy(CartAggregateRoot::class)] class AddCartItem { public function __construct( #[AggregateUuid] public string $cartUuid, public string $cartItemUuid, public string $sku, public int $quantity, ) {} } ``` E l'aggregate root riceve il command direttamente come metodo, senza handler intermediari: ```php // app/Domain/Cart/CartAggregateRoot.php use Spatie\EventSourcing\AggregateRoots\AggregateRoot; class CartAggregateRoot extends AggregateRoot { private array $items = []; public function addCartItem(AddCartItem $command): void { if (count($this->items) >= 50) { throw new \DomainException('Limite massimo di 50 articoli per carrello'); } $this->recordThat(new CartItemAdded( cartItemUuid: $command->cartItemUuid, sku: $command->sku, quantity: $command->quantity, )); } protected function applyCartItemAdded(CartItemAdded $event): void { $this->items[$event->cartItemUuid] = [ 'sku' => $event->sku, 'quantity' => $event->quantity, ]; } } ``` Da un controller, dispatchi un command sul `CommandBus` di Spatie: ```php // app/Http/Controllers/Api/CartController.php use Spatie\EventSourcing\Commands\CommandBus; public function addItem(Request $request, CommandBus $bus, string $cartUuid): JsonResponse { $bus->dispatch(new AddCartItem( cartUuid: $cartUuid, cartItemUuid: (string) Str::uuid(), sku: $request->validated('sku'), quantity: $request->validated('quantity'), )); return response()->json(['status' => 'queued'], 202); } ``` Tre dettagli operativi che ti salvano in produzione. Primo, **abilita la cache dei projector e reactor scoperti** in `config/event-sourcing.php` (opzione `cache_path`), altrimenti su ogni request Laravel re-scansiona la directory. Secondo, **dedica una coda specifica a un singolo worker** (`processes => 1`): gli eventi devono essere processati in ordine, ed è esattamente la garanzia che vuoi su un sistema event-sourced. Su Horizon configura un supervisor dedicato `event-sourcing-supervisor-1` con `balance: simple`. Terzo, **non usare lo stesso DB della web application come event store su carichi alti**: dopo qualche milione di eventi le query di replay diventano lente, e isolare l'event store su un DB dedicato (anche solo logicamente) ti permette di gestire il sizing in modo indipendente. Una nota di disambiguazione importante per chi viene dal mondo CRUD: Event Sourcing **non** è la stessa cosa degli "eventi Laravel" che ascolti con `Event::listen()` o con l'attributo `#[AsEventListener]`. Quelli sono notifiche asincrone interne all'applicazione, mentre gli eventi di un sistema Event Sourced sono fatti di dominio persistiti come source of truth. Se stai modernizzando il sistema di eventi ordinario di Laravel - ad esempio passando dall'array `$listen` all'event discovery - quel refactoring rientra in un altro tipo di intervento, che ho coperto nell'articolo su [come modernizzare la gestione eventi Laravel con `#[AsEventListener]` in L12](https://www.mauriziofonte.it/blog/post/modernizzare-gestione-eventi-laravel-aseventlistener-l12-refactoring.html). Sono due livelli architetturali diversi e confonderli porta a errori di scope. ## Il tranello GDPR: immutabilità degli eventi vs diritto all'oblio Questo è il punto che gli articoli sbrigativi su Event Sourcing non affrontano, e che invece va affrontato per primo se la tua applicazione tocca dati personali. Il GDPR all'[art. 17](https://eur-lex.europa.eu/eli/reg/2016/679/oj) garantisce all'interessato il diritto alla cancellazione dei propri dati. Un event store immutabile, per definizione, non cancella nulla. C'è un conflitto diretto. Le due strategie operative che ho applicato: - **Crypto-shredding.** Ogni evento che contiene dati personali viene cifrato con una chiave dedicata per soggetto interessato. Quando arriva una richiesta di cancellazione GDPR, non cancelli gli eventi: cancelli la chiave. Gli eventi diventano matematicamente illeggibili, soddisfacendo lo scopo dell'art. 17 ("rendere i dati non più disponibili") senza rompere l'immutabilità del log. È l'approccio raccomandato da [HashiCorp con Vault per event sourcing GDPR-compliant](https://www.hashicorp.com/en/resources/gdpr-compliant-event-sourcing-with-hashicorp-vault), e l'ho implementato su Laravel usando Vault Transit come provider di chiavi. - **Eventi "dummy" di censura.** Un evento speciale `PersonalDataRedacted` che, replayato, sostituisce tutti i campi PII di una serie di eventi precedenti. Più semplice del crypto-shredding ma non garantisce che i dati originali non siano rimasti in backup o snapshot. Da preferire solo se hai un piano di rotazione dei backup compatibile. In entrambi i casi serve coordinamento con il DPO e con la documentazione del registro dei trattamenti. Per i pattern operativi di gestione GDPR su Laravel ho coperto i casi più comuni nella [checklist d'emergenza GDPR per Laravel](https://www.mauriziofonte.it/blog/post/gestione-urgente-gdpr-laravel-sicurezza.html), e per il quadro NIS2 più ampio ho scritto la mia [guida pratica alla compliance NIS2 per server Hetzner/OVH](https://www.mauriziofonte.it/blog/post/direttiva-nis2-guida-compliance-server-hetzner-ovh.html). Nessuna delle due strategie è gratis: il crypto-shredding richiede un sistema di gestione chiavi solido (KMS o Vault, non file su disco), gli eventi di censura richiedono che il replay dell'event store gestisca correttamente l'ordine logico. Sono tecnicamente fattibili ma sono l'opposto del "plug-and-play". Questa è una delle ragioni per cui per la maggior parte delle PMI consiglio la route audit-chain immutabile con hash: il GDPR si gestisce con `DELETE` mirate sui campi PII di una tabella di audit normale, e la garanzia di non manomissione viene dalla catena di hash, non dall'immutabilità del database. Event Sourcing è uno degli strumenti più potenti del bagaglio di un architetto Laravel moderno, ma è anche uno dei più costosi da adottare male. La domanda giusta da farsi non è "come implemento Event Sourcing", è "quale problema sto risolvendo, e qual è la soluzione minima sufficiente". Per il cliente biomedicale di cui ti raccontavo, la minima sufficiente è stata audit-chain con hash; per un altro cliente del settore fintech che aveva bisogno di ricostruire saldi storici per audit BCE, la minima sufficiente è stata Spatie event-sourcing con CQRS sul dominio specifico dei movimenti finanziari, lasciando il resto dell'applicazione come CRUD normale. La differenza la fa la diagnosi prima dell'implementazione. Se stai valutando un'iniziativa di tracciabilità o audit per la tua applicazione Laravel e vuoi capire qual è la strada giusta per il tuo caso senza buttare mesi di sviluppo nella direzione sbagliata, [scopri il mio approccio professionale ai temi di architettura Laravel](https://www.mauriziofonte.it/pages/about) - lavoro con Laravel da Laravel 4 e ho visto entrambi gli scenari (Event Sourcing che funziona benissimo, e Event Sourcing che diventa una palla al piede). Se vuoi una valutazione concreta del tuo caso specifico, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): in due settimane di audit ti consegno una raccomandazione architetturale supportata da numeri (effort, rischio, payoff) e una decisione che puoi portare al CdA con onestà tecnica. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteTesting di API Laravel con Pest 3 nel 2026: dataset, mutation testing e CI per PMI che vogliono dormire20 Marzo 2025](https://www.mauriziofonte.it/blog/post/laravel-pest-api-testing-pmi-backend-stabilita-affidabilita-ci-cd.html)[Articolo successivo »Perché il "fai-da-te" informatico sta costando caro alla tua azienda8 Aprile 2025](https://www.mauriziofonte.it/blog/post/rischi-costi-fai-da-te-it-aziende.html) ### Articoli correlati a Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici - [CQRS in PHP: separare letture e scritture per applicazioni Laravel ad alto carico](https://www.mauriziofonte.it/blog/post/cqrs-php-laravel-separare-letture-scritture-alto-carico.html) Un'applicazione di reportistica con 50 query analitiche complesse che rallentavano le operazioni transazionali. Con CQRS ho separato i modelli · 9 Dicembre 2025 ![CQRS in PHP: separare letture e scritture per applicazioni Laravel ad alto carico](https://www.mauriziofonte.it/image/003220070-cqrs-php-laravel-separare-letture-scritture-alto-carico.jpg) - [Event discovery in Laravel 12: da EventServiceProvider a auto-discovery per listener disaccoppiati e testabili](https://www.mauriziofonte.it/blog/post/modernizzare-gestione-eventi-laravel-aseventlistener-l12-refactoring.html) L'event discovery scansiona automaticamente i listener nella directory app/Listeners e li registra in base al type hint del metodo handle . Introdotto · 26 Febbraio 2025 ![Event discovery in Laravel 12: da EventServiceProvider a auto-discovery per listener disaccoppiati e testabili](https://www.mauriziofonte.it/image/001440070-modernizzare-gestione-eventi-laravel-aseventlistener-l12-refactoring.jpg) - [Domain-Driven Design con Laravel: implementare bounded contexts in un progetto reale](https://www.mauriziofonte.it/blog/post/domain-driven-design-laravel-bounded-contexts-progetto-reale.html) DDD viene spesso presentato come una soluzione per tutti i problemi architetturali, ma in pratica richiede una comprensione profonda del dominio · 5 Dicembre 2025 ![Domain-Driven Design con Laravel: implementare bounded contexts in un progetto reale](https://www.mauriziofonte.it/image/003320070-domain-driven-design-laravel-bounded-contexts-progetto-reale.jpg) - [Fat Controller in Laravel 12: dal controller da 200 righe a Service Layer, Action pattern e Dependency Injection](https://www.mauriziofonte.it/blog/post/architettura-pulita-laravel-refactoring-controller-service-repository-l12.html) Robert C. Martin definisce il Single Responsibility Principle come "un modulo deve essere responsabile verso un solo attore". Un controller Laravel · 11 Marzo 2025 ![Fat Controller in Laravel 12: dal controller da 200 righe a Service Layer, Action pattern e Dependency Injection](https://www.mauriziofonte.it/image/001520070-architettura-pulita-laravel-refactoring-controller-service-repository-l12.jpg) - [Audit trail e logging di business in Laravel: tracciare ogni azione senza impattare le prestazioni](https://www.mauriziofonte.it/blog/post/audit-trail-logging-business-laravel-senza-impatto-prestazioni.html) Un'applicazione finanziaria richiedeva di tracciare ogni modifica a ogni record chi ha fatto cosa, quando, con quale valore precedente. La soluzione · 5 Febbraio 2026 ![Audit trail e logging di business in Laravel: tracciare ogni azione senza impattare le prestazioni](https://www.mauriziofonte.it/image/003060070-audit-trail-logging-business-laravel-senza-impatto-prestazioni.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/laravel-event-sourcing-pmi-audit-tracciabilita-cqrs-spatie-event-projector.html Pubblicato: 2025-03-21 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.