DEV Community: Dev-Iadicola

Domain-Driven Design: modellare il software attorno al business

Dev-Iadicola — Mon, 20 Jul 2026 17:00:27 +0000

Il problema: software che non parla la lingua del business

Un gestionale per un'azienda di logistica ha una classe Item che viene usata per i prodotti in magazzino, per le righe degli ordini, per i pacchi in spedizione e per le voci di fatturazione. Quattro concetti diversi, una sola classe. Quando il team di magazzino parla di "item", intende un prodotto fisico con peso e dimensioni. Quando il team di fatturazione parla di "item", intende una voce con prezzo e tasse. Il codice non distingue i due significati e questo genera bug, fraintendimenti e complessità accidentale.

Il Domain-Driven Design (DDD), proposto da Eric Evans nel 2003, affronta questo problema alla radice: il software deve modellare il dominio di business usando il linguaggio del business. Non il linguaggio dei programmatori — il linguaggio degli esperti di dominio.

Ubiquitous Language: parlare la stessa lingua

Il primo principio del DDD e l'Ubiquitous Language: un vocabolario condiviso tra sviluppatori e esperti di dominio, usato nel codice, nelle conversazioni e nella documentazione. Se l'esperto di magazzino dice "picking list", il codice ha una classe PickingList. Se l'esperto di fatturazione dice "nota di credito", il codice ha una classe NotaDiCredito. Non CreditNoteEntity o InvoiceItemDTO — il nome nel codice e il nome nel dominio.

Bounded Context: confini di significato

Un Bounded Context e un confine entro il quale un termine ha un significato preciso. "Item" nel contesto Magazzino e un prodotto fisico. "Item" nel contesto Fatturazione e una voce economica. Sono due classi diverse in due contesti diversi, non una classe condivisa con flag e condizioni.

Contesto Magazzino: Product con peso, dimensioni, posizione scaffale, quantità
Contesto Ordini: OrderLine con prodotto riferito per ID, quantità ordinata, prezzo al momento dell'ordine
Contesto Fatturazione: InvoiceLine con descrizione, importo, aliquota IVA
Contesto Spedizione: Parcel con peso totale, dimensioni, indirizzo destinatario

Ogni contesto ha il proprio modello, ottimizzato per le proprie esigenze. I contesti comunicano tramite interfacce esplicite o eventi, non condividendo classi.

Building blocks tattici

Entity

Un oggetto con identita: due ordini con gli stessi prodotti sono comunque ordini diversi perché hanno ID diversi. L'identita persiste attraverso i cambiamenti di stato.

Value Object

Un oggetto senza identita, definito solo dai suoi valori: Money(100, 'EUR') e uguale a un altro Money(100, 'EUR'). I Value Object sono immutabili. Email, Address, DateRange sono Value Object classici. In PHP si implementano come classi readonly con validazione nel costruttore.

Aggregate

Un cluster di Entity e Value Object con un Aggregate Root come unico punto di accesso. Order (root) contiene OrderLine (entity interna). Non accedi mai a un OrderLine senza passare dall'Order. L'Aggregate garantisce la consistenza interna: le regole di business (es. "il totale non può essere negativo") sono verificate dall'Aggregate Root.

Domain Event

Un fatto accaduto nel dominio: OrderPlaced, PaymentReceived. Gli eventi permettono ai Bounded Context di comunicare senza accoppiamento diretto.

Repository

L'interfaccia per persistere e recuperare Aggregate. Definita nel dominio, implementata nell'infrastruttura. Un Aggregate = un Repository.

DDD in PHP: e praticabile?

Si, con alcune accortezze. PHP 8.1+ con readonly properties, enum e named arguments rende i Value Object naturali. Le interfacce per i Repository e il Dependency Injection sono supportati nativamente. I Domain Event si implementano con un semplice dispatcher. Il costo principale e culturale: il team deve investire tempo nell'analisi del dominio con gli esperti di business.

Quando usare DDD

Usa DDD quando il dominio e complesso e le regole di business sono il cuore del valore dell'applicazione
Usa DDD quando ci sono esperti di dominio disponibili per collaborare con il team tecnico
Usa DDD quando il linguaggio del business e confuso e serve una modellazione esplicita
Non usare DDD per CRUD senza logica di business significativa: il costo di modellazione non si ripaga
Non usare DDD se non hai accesso agli esperti di dominio: DDD senza domain expert e un esercizio accademico

DDD non e un'architettura: e un approccio alla modellazione. Si combina con qualsiasi architettura — MVC, Hexagonal, Clean, CQRS. Il suo valore non e nelle classi o nelle interfacce, ma nel modo di pensare al software: partendo dal dominio, non dalla tecnologia.

👉 Leggi l'articolo completo su iadicola.it

Hexagonal Architecture: il dominio al centro, il framework ai margini

Dev-Iadicola — Fri, 17 Jul 2026 17:00:13 +0000

Il problema: il framework che diventa il padrone

In un'applicazione Laravel tipica, la business logic dipende da Eloquent, da Facade, da Request, da Mail. Se Laravel cambia un'API interna, il tuo dominio si rompe. Se vuoi testare la logica senza database, non puoi — e tutto accoppiato. Se un giorno devi migrare a Symfony (succede), devi riscrivere tutto. Il framework dovrebbe essere un dettaglio implementativo, non il fondamento su cui il dominio si regge.

L'Architettura Esagonale, proposta da Alistair Cockburn nel 2005, inverte questa dipendenza: il dominio e al centro, autosufficiente. Il framework, il database, le API esterne sono alla periferia, collegati tramite Ports (interfacce) e Adapters (implementazioni).

Ports and Adapters: la struttura

L'esagono (la forma e metaforica, non geometrica) ha tre zone:

Core (Domain): al centro. Contiene entita, value objects, regole di business, interfacce dei repository. Non importa nulla dal framework. Zero dipendenze esterne.
Ports: interfacce che definiscono come il dominio comunica con l'esterno. Driving ports (primari): come il mondo esterno usa il dominio (es. OrderServiceInterface). Driven ports (secondari): come il dominio usa il mondo esterno (es. OrderRepositoryInterface, PaymentGatewayInterface).
Adapters: implementazioni concrete dei ports. Un adapter HTTP traduce una request in una chiamata al driving port. Un adapter PostgreSQL implementa il driven port del repository. Un adapter Stripe implementa il driven port del gateway di pagamento.

Esempio teorico: un sistema di pagamenti

Il dominio definisce un'interfaccia PaymentGatewayInterface con charge(Money $amount, Card $card): PaymentResult. Il dominio non sa se il pagamento passa da Stripe, PayPal o Satispay. Sa solo che esiste un gateway che accetta un importo e una carta e restituisce un risultato.

StripePaymentAdapter implementa l'interfaccia usando l'SDK di Stripe
PayPalPaymentAdapter implementa la stessa interfaccia usando l'API PayPal
FakePaymentAdapter implementa l'interfaccia per i test — approva sempre, senza rete

Cambiare gateway di pagamento richiede una sola modifica: quale adapter viene iniettato. Il dominio — con tutte le sue regole su limiti di importo, retry, idempotenza — non cambia di una riga.

Hexagonal vs MVC: non si escludono

MVC e Hexagonal non sono alternative: sono complementari. MVC organizza il flusso HTTP (request → controller → view). Hexagonal organizza la struttura interna dell'applicazione (dominio → ports → adapters). Un'applicazione può usare MVC per il layer HTTP e Hexagonal per la struttura del dominio.

In pratica: il Controller (MVC) e un adapter HTTP (Hexagonal) che traduce la request in una chiamata a un driving port (l'interfaccia del Service). Il Repository Eloquent e un adapter di persistenza che implementa un driven port (l'interfaccia del Repository definita nel dominio).

La regola della dipendenza

La regola fondamentale dell'Hexagonal Architecture e la direzione delle dipendenze: tutto punta verso il centro. Gli adapter dipendono dai ports. I ports dipendono dal dominio. Il dominio non dipende da nulla. Mai una use Illuminate\... dentro una classe di dominio. Mai un use Doctrine\... in un'entita.

Questa regola sembra rigida ma produce un beneficio concreto: puoi testare l'intero dominio con mock dei ports — senza database, senza HTTP, senza servizi esterni. I test girano in millisecondi e testano la logica pura.

Quando usare l'Hexagonal Architecture

Usa Hexagonal quando la business logic e complessa e deve sopravvivere al framework
Usa Hexagonal quando il progetto ha una vita lunga (anni) e il framework potrebbe cambiare
Usa Hexagonal quando la testabilita del dominio e una priorità
Non usare Hexagonal per CRUD semplici: il layer di astrazione aggiuntivo non paga il costo
Non usare Hexagonal se il team non e pronto: la curva di apprendimento e reale

L'Hexagonal Architecture non e una moda: e una risposta strutturale al problema dell'accoppiamento con il framework. Quando il dominio e al centro e il framework e ai margini, il codice che conta — la business logic — e protetto, testabile e portabile.

👉 Leggi l'articolo completo su iadicola.it

Serverless PHP: quando ha senso e come funziona con Bref

Dev-Iadicola — Thu, 16 Jul 2026 17:00:14 +0000

Serverless non significa "senza server"

Il termine "serverless" e fuorviante: i server esistono, semplicemente non li gestisci tu. Il cloud provider (AWS, Google Cloud, Azure) si occupa di provisioning, scaling, patching e monitoring dell'infrastruttura. Tu deployi codice e paghi per esecuzione — niente VPS da mantenere, niente Apache da configurare, niente aggiornamenti di sicurezza del sistema operativo.

Per anni, PHP e stato escluso dal mondo serverless dominato da Node.js e Python. Bref ha cambiato le cose: e un runtime PHP open-source per AWS Lambda che permette di deployare applicazioni PHP — incluse applicazioni Laravel e Symfony — su infrastruttura serverless.

Come funziona Bref

Bref fornisce Lambda layers con il runtime PHP precompilato. Il tuo codice viene impacchettato e caricato su Lambda. Quando arriva una richiesta, Lambda avvia un'istanza del runtime, esegue il codice e restituisce il risultato. Se arrivano 1000 richieste simultanee, Lambda avvia 1000 istanze. Se non arrivano richieste per 15 minuti, le istanze vengono terminate. Paghi solo per il tempo di esecuzione effettivo.

Bref offre tre modalita:

Web function: gestisce richieste HTTP tramite API Gateway. Adatta per applicazioni web complete.
Event-driven function: risponde a eventi (SQS, S3, EventBridge). Adatta per job, processing, integrations.
Console function: esegue comandi CLI (Artisan, Symfony Console). Adatta per cron job e task schedulati.

Vantaggi concreti

Costo a consumo: paghi per millisecondo di esecuzione. Un'applicazione con poco traffico costa centesimi al mese. Un VPS costa 5-20 EUR/mese anche se non riceve traffico.
Scaling automatico: da 0 a migliaia di istanze senza configurazione. Nessun capacity planning, nessun autoscaling group da configurare.
Zero manutenzione server: niente aggiornamenti OS, niente patch di sicurezza, niente monitoring dell'infrastruttura.
Deploy atomici: ogni deploy e una nuova versione della funzione. Rollback istantaneo alla versione precedente.

I limiti reali

Cold start: la prima invocazione dopo un periodo di inattivita richiede 200-800ms per avviare il runtime PHP. Per applicazioni interattive con requisiti di latenza stretti, può essere un problema.
Tempo massimo di esecuzione: Lambda ha un timeout di 15 minuti. Job di lunga durata non sono adatti.
Filesystem effimero: /tmp ha 512MB-10GB ma viene cancellato tra le invocazioni. File upload e processing richiedono S3.
Sessioni: senza filesystem persistente, le sessioni PHP devono usare DynamoDB, Redis o un altro store esterno.
Vendor lock-in: il codice diventa dipendente da AWS. Migrare a un altro provider o a un VPS richiede lavoro.

Casi d'uso ideali per PHP serverless

API con traffico variabile: un'API che ha picchi durante il giorno e zero traffico di notte. Paghi solo quando viene usata.
Webhook e integrazioni: endpoint che ricevono callback da servizi esterni (Stripe, GitHub, Mailgun). Traffico imprevedibile e sporadico.
Processing asincrono: generazione PDF, resize immagini, invio email batch. Event-driven, senza server dedicato.
Cron job: task schedulati che girano per pochi secondi al giorno. Pagare un VPS 24/7 per 30 secondi di lavoro non ha senso.

Quando NON usare serverless

Applicazioni con traffico costante: se il server e sempre occupato, un VPS dedicato costa meno di Lambda
WebSocket e connessioni persistenti: Lambda non supporta connessioni long-lived
Applicazioni con stato locale: file system, cache in-memory, sessioni PHP native non funzionano
Team senza esperienza AWS: la curva di apprendimento di IAM, API Gateway, CloudFormation e reale

Serverless PHP con Bref non e la soluzione universale, ma per i casi d'uso giusti — traffico variabile, processing asincrono, cron job — offre un rapporto costo/semplicità che nessun VPS può eguagliare. Il futuro di PHP non e solo Apache su un server: e anche funzioni che si avviano in millisecondi e si spengono quando non servono.

👉 Leggi l'articolo completo su iadicola.it

CQRS: separare lettura e scrittura per scalare e semplificare

Dev-Iadicola — Wed, 15 Jul 2026 17:00:13 +0000

Il problema: un modello che fa tutto

In un e-commerce, il modello Order serve sia per creare/modificare ordini (scrittura) sia per visualizzare la lista ordini, i report e le dashboard (lettura). Ma le esigenze sono opposte: la scrittura ha bisogno di validazione, regole di business e transazioni atomiche. La lettura ha bisogno di query ottimizzate, join complessi, aggregazioni e cache. Un singolo modello che fa entrambe le cose diventa un compromesso permanente.

CQRS (Command Query Responsibility Segregation) propone di separare i due percorsi: un modello per la scrittura (Commands) e un modello per la lettura (Queries). Ognuno ottimizzato per il proprio scopo, senza compromessi.

Command e Query: le due meta

Commands: modificare lo stato

Un Command rappresenta un'intenzione di cambiare lo stato del sistema: CreateOrderCommand, CancelOrderCommand, UpdateAddressCommand. Il Command contiene i dati necessari per l'operazione. Un Command Handler riceve il Command, esegue la validazione di business, modifica lo stato e persiste. I Command non restituiscono dati (al massimo un ID o un acknowledge).

Queries: leggere lo stato

Una Query rappresenta una richiesta di dati: GetOrderDetailsQuery, ListPendingOrdersQuery, GetMonthlySalesReportQuery. Un Query Handler riceve la Query e restituisce dati. Le Query non modificano mai lo stato — sono pure letture.

Perché separare: vantaggi concreti

Ottimizzazione indipendente: il modello di scrittura usa un ORM con validazione e regole. Il modello di lettura usa query SQL dirette, viste materializzate, cache aggressiva. Nessun compromesso.
Scalabilità asimmetrica: la maggior parte delle applicazioni legge 10x più di quanto scrive. Con CQRS puoi scalare il read path (cache, repliche) senza toccare il write path.
Modelli dedicati: il DTO di lettura per la dashboard ha campi diversi dall'entita di dominio. Con CQRS sono modelli separati, non proiezioni forzate dello stesso oggetto.
Testabilita: Command Handler e Query Handler sono unita testabili indipendentemente.

CQRS senza Event Sourcing

Un malinteso comune e che CQRS richieda Event Sourcing. Non e così. CQRS e la separazione dei modelli di lettura e scrittura — può usare lo stesso database con tabelle diverse, o lo stesso database con query diverse. Event Sourcing e un pattern complementare ma opzionale che aggiunge la persistenza degli eventi come fonte di verità.

La forma più semplice di CQRS in PHP: il Command Handler usa Eloquent per validare e salvare. Il Query Handler usa query SQL dirette o viste per leggere. Stesso database, due percorsi.

Esempio pratico in PHP

Write side: CreateOrderHandler riceve un CreateOrderCommand, valida il carrello, verifica il stock, calcola il totale, crea l'ordine tramite il Repository, dispara eventi
Read side: OrderDashboardQuery esegue una singola query SQL con join e aggregazioni che restituisce i dati esatti per la dashboard — nessun ORM, nessun N+1, nessun over-fetching

Quando usare CQRS

Usa CQRS quando le esigenze di lettura e scrittura sono significativamente diverse
Usa CQRS quando la lettura e il collo di bottiglia e vuoi ottimizzarla indipendentemente
Usa CQRS quando i report e le dashboard richiedono strutture dati diverse dalle entita di dominio
Non usare CQRS per CRUD semplici dove lettura e scrittura usano lo stesso modello senza problemi
Non usare CQRS se il team non distingue chiaramente Command da Query: la separazione forzata diventa confusione

CQRS non e un'architettura completa: e un principio di separazione. Applicato nei punti giusti — dove lettura e scrittura hanno requisiti diversi — semplifica entrambi i percorsi. Applicato ovunque per dogma, aggiunge complessità senza beneficio.

👉 Leggi l'articolo completo su iadicola.it

Un gestionale di magazzino costruito attorno a chi lavora in magazzino

Dev-Iadicola — Mon, 13 Jul 2026 17:00:23 +0000

Un gestionale di magazzino costruito attorno a chi lavora in magazzino

Ogni magazzino vive di una domanda continua: cosa è entrato, cosa è uscito, e dove si trova adesso? Sembra semplice, ma chiunque ci abbia lavorato sa che la realtà è fatta di terminali condivisi, operatori che si alternano, merce che esce prima di essere registrata e inventari che non tornano mai. Ho progettato questo gestionale partendo proprio da quei problemi concreti, e quasi ogni decisione tecnica nasce da una frustrazione vera del lavoro quotidiano.

Ne racconto qui le più interessanti — non perché siano complicate, ma perché ognuna risolve un problema che chi gestisce un magazzino riconosce al volo.

Si entra col PIN, non con email e password

In un magazzino il computer (o il tablet) è uno solo e lo usano in tanti, a turno. Chiedere a ogni operatore di fare logout e poi login con email e password ogni volta che si avvicina al terminale è una di quelle cose che, sulla carta, funziona — e nella pratica nessuno fa. Risultato classico: tutti lavorano con lo stesso utente e diventa impossibile sapere chi ha fatto cosa.

La soluzione qui è diversa. Il terminale resta acceso e "loggato" praticamente sempre, per mesi. Ma ogni movimento richiede un PIN di 4 cifre personale: l'operatore digita il suo codice, fa l'operazione, e quel movimento resta legato al suo nome per sempre. Il PIN "scade" dopo pochi minuti di inattività, così il sistema chiede di reinserirlo e non rischia mai di attribuire un'operazione alla persona sbagliata.

È un doppio orologio pensato apposta: uno lento, che tiene il dispositivo pronto all'uso e non costringe a riloggarsi di continuo; uno veloce, che garantisce la tracciabilità reale di ogni singolo gesto. Per chi entra e esce dal terminale venti volte al giorno cambia tutto.

L'app capisce da sola se è una vendita o un consumo interno

Quando la merce esce dal magazzino, può uscire per due motivi molto diversi: o viene venduta a un cliente, oppure viene consumata internamente dalla produzione. Sono due cose che vanno registrate in modo diverso, e di solito si chiede all'operatore di scegliere ogni volta da un menù. Ogni scelta manuale è un'occasione per sbagliare.

Qui l'app lo capisce da sola, in base a chi sta lavorando. Un operatore "normale" scarica sempre verso un cliente; un operatore della produzione scarica sempre verso la produzione. Chi usa il sistema non deve decidere nulla: fa il suo lavoro e la classificazione corretta arriva automaticamente. Il supervisore, che ha una visione completa, è l'unico che può scegliere manualmente quando serve.

Meno scelte da fare significa meno errori, e numeri di fine mese che tornano.

Creare un articolo "al volo", senza bloccare la merce

Capita spessissimo: arriva un bancale, l'operatore scansiona il codice a barre e… quell'articolo non esiste ancora a sistema. La reazione naturale sarebbe mettere tutto in pausa, chiamare il responsabile, far creare la scheda. Nel frattempo la merce resta lì e il lavoro si ferma.

Con questo gestionale, se la funzione è attiva, l'operatore può creare l'articolo sul momento, direttamente dalla schermata di carico, compilando un piccolo modulo veloce. L'articolo nasce subito ed è immediatamente disponibile per essere caricato. La merce entra, il lavoro non si ferma, e il supervisore potrà completare i dettagli con calma in un secondo momento.

L'inventario si conta "alla cieca"

Il momento dell'inventario fisico è quello in cui i conti dovrebbero tornare — ed è proprio quello in cui si bara di più, spesso senza volerlo. Se l'operatore vede a schermo "a sistema risultano 100 pezzi", è umano che, contandone 98, finisca per scrivere 100 "tanto è quello giusto".

Qui durante la conta l'operatore non vede mai la quantità attesa: inserisce soltanto quello che conta davvero. Solo dopo, il supervisore confronta il conteggio con i dati di sistema, vede le differenze e decide cosa fare. Se approva, è il sistema stesso a generare in automatico le rettifiche necessarie per allineare le giacenze.

È una conta più onesta, e una correzione tracciata: si sa sempre quale rettifica è nata da quale inventario.

Le giacenze possono andare in negativo (e va bene così)

Molti gestionali bloccano lo scarico se a sistema "non c'è abbastanza merce". Sembra prudente, ma nella realtà è il contrario: la merce magari è già uscita fisicamente e semplicemente non è ancora stata registrata. Bloccare l'operazione costringe le persone a "barare" pur di andare avanti, e il dato diventa ancora meno affidabile.

Questo sistema permette alla giacenza di scendere sotto lo zero, perché preferisce registrare la verità piuttosto che una finzione ordinata. Però, appena succede, fa scattare un avviso per il supervisore. E gli avvisi sono intelligenti: non ripetono lo stesso allarme all'infinito, ma segnalano una sola volta finché la situazione non cambia davvero. Così le notifiche restano utili invece di diventare rumore da ignorare.

Trovare un articolo in un istante

Cercare un prodotto è l'azione più frequente in assoluto. Per questo la ricerca funziona sia per codice (anche il codice a barre) sia per descrizione, e restituisce subito la posizione in magazzino, la quantità disponibile e il fornitore. Niente filtri complicati: si scrive e si trova.

I permessi li decide il responsabile, non il programmatore

Le regole di un magazzino cambiano nel tempo: oggi un certo ruolo può fare una cosa, domani no. Di solito modificare "chi può fare cosa" significa chiamare lo sviluppatore e aspettare un aggiornamento.

Qui il supervisore ha a disposizione una tabella dei permessi che può modificare da solo, con qualche clic: decide quali ruoli possono creare articoli, approvare inventari, gestire utenti e così via. Le regole si adattano all'organizzazione senza bisogno di toccare il codice.

E ogni modifica importante — agli articoli, ai fornitori, ai PIN degli utenti — viene registrata in un diario delle attività: chi, cosa, quando. Una rete di sicurezza per quando serve capire come si è arrivati a una certa situazione.

Sotto il cofano, in breve

Senza entrare nel tecnico: l'applicazione gira interamente nel browser, quindi funziona da computer, tablet o smartphone senza installare nulla, e la scansione dei codici a barre può usare sia un lettore fisico sia la fotocamera del telefono. È costruita con tecnologie web moderne e ampiamente collaudate, pensate per restare veloci e reattive anche con molti operatori che lavorano contemporaneamente.

La filosofia, alla fine

Il filo conduttore di tutte queste scelte è uno solo: la tecnologia deve adattarsi al modo in cui si lavora davvero in magazzino, non il contrario. Niente passaggi inutili imposti all'operatore, niente dati "puliti" ma falsi, niente regole rigide che costringono a trovare scorciatoie. Un gestionale che riduce gli errori non perché controlla di più le persone, ma perché chiede loro di pensare di meno alle cose che la macchina può capire da sola.

👉 Leggi l'articolo completo su iadicola.it

Mediator Pattern: comunicazione senza caos

Dev-Iadicola — Sun, 12 Jul 2026 17:00:36 +0000

Il problema: tutti parlano con tutti

Un form complesso ha 10 campi interdipendenti. Selezionare "tipo: azienda" mostra il campo P.IVA e nasconde il codice fiscale. Selezionare "paese: estero" disabilita il CAP e cambia il formato del telefono. Cambiare la provincia aggiorna la lista dei comuni. Ogni campo conosce gli altri e li manipola direttamente: $tipoField->onChange(function() use ($pivaField, $cfField) { ... }).

Con 10 campi che comunicano tra loro hai potenzialmente 90 connessioni dirette (N*(N-1)). Aggiungere l'undicesimo campo richiede di aggiornare tutti quelli che interagiscono con esso. Rimuoverne uno rompe tutti quelli che lo referenziano. E un groviglio che nessuno vuole toccare.

Il Mediator Pattern introduce un coordinatore centrale: i campi non comunicano tra loro, comunicano con il mediator. Il mediator conosce le regole di interazione e coordina le risposte. Ogni campo conosce solo il mediator, non gli altri campi.

Cos'e il Mediator Pattern: definizione formale

Il Gang of Four definisce il Mediator come un pattern comportamentale che "definisce un oggetto che incapsula come un insieme di oggetti interagisce. Il Mediator promuove l'accoppiamento lasco impedendo agli oggetti di riferirsi esplicitamente l'un l'altro". La struttura prevede:

Mediator: l'interfaccia con un metodo notify(sender, event)
ConcreteMediator: implementa la logica di coordinamento tra i componenti
Colleague: ogni componente che comunica tramite il mediator. Conosce il mediator, non gli altri colleague.

Esempio teorico: una chat room

Una chat room e l'esempio classico del Mediator. Ogni utente (Colleague) invia messaggi alla room (Mediator), non direttamente agli altri utenti. La room decide chi riceve il messaggio: tutti (broadcast), un gruppo (canale), o un singolo utente (messaggio privato).

ChatRoom::notify(User $sender, string $message, ?string $channel) riceve il messaggio
Se il canale e specificato, inoltra solo ai membri del canale
Se e un messaggio privato (@user), inoltra solo al destinatario
Altrimenti, broadcast a tutti tranne il mittente

Aggiungere un utente alla room non richiede di modificare gli altri utenti. Aggiungere regole (moderazione, filtro spam, rate limiting) richiede di modificare solo il mediator. I colleague restano semplici.

Esempio teorico: orchestrazione di microservizi

Un ordine e-commerce coinvolge: inventario, pagamento, spedizione, notifiche, fatturazione. Senza mediator, ogni servizio chiama gli altri direttamente — un groviglio di dipendenze. Con un OrderOrchestrator (mediator), il flusso diventa lineare: il payment service notifica l'orchestrator "pagamento riuscito", l'orchestrator chiama l'inventario per riservare, poi la spedizione per preparare, poi la fatturazione per emettere, poi le notifiche per informare il cliente.

Mediator vs Observer

Observer: comunicazione one-to-many. Un subject notifica tutti gli observer. Gli observer non si conoscono ma il subject non coordina le loro risposte.
Mediator: comunicazione many-to-many coordinata. Il mediator riceve notifiche da qualsiasi colleague e decide come e chi coinvolgere nella risposta.

L'Observer e passivo: "e successo X, fate quello che volete". Il Mediator e attivo: "e successo X, quindi tu fai A, tu fai B, e tu aspetti". Se serve coordinamento tra le risposte, il Mediator e la scelta giusta.

Quando usare il Mediator Pattern

Usa il Mediator quando molti oggetti comunicano tra loro in modi complessi e le dipendenze dirette sono un groviglio
Usa il Mediator quando vuoi centralizzare le regole di interazione in un unico punto modificabile
Usa il Mediator quando aggiungere o rimuovere un componente non deve richiedere modifiche agli altri
Non usare il Mediator se i componenti hanno interazioni semplici e dirette: il mediator aggiunge un layer di indirezione non necessario
Attenzione: il mediator può diventare un God Object se accumula troppa logica. Se cresce troppo, suddividilo in sotto-mediator specializzati.

Il Mediator Pattern e il pattern del coordinamento centralizzato: trasforma una rete di dipendenze N-a-N in una stella con il mediator al centro. La complessità non scompare — si sposta in un punto unico, visibile e manutenibile.

👉 Leggi l'articolo completo su iadicola.it

Memento Pattern: catturare e ripristinare lo stato

Dev-Iadicola — Sat, 11 Jul 2026 17:00:35 +0000

Il problema: tornare indietro senza rompere l'incapsulamento

Un editor di testo deve supportare l'undo. Per annullare un'operazione, serve lo stato precedente del documento. La soluzione ingenua e rendere pubbliche tutte le proprieta dell'editor per poterle salvare dall'esterno. Ma questo viola l'incapsulamento: il codice che gestisce l'undo conosce i dettagli interni dell'editor, e se la struttura interna cambia, il sistema di undo si rompe.

Il Memento Pattern risolve il dilemma: l'oggetto stesso crea uno snapshot del proprio stato (il memento) e lo fornisce all'esterno come oggetto opaco. Chi gestisce la history (il caretaker) conserva i memento senza poterne leggere il contenuto. Solo l'oggetto originale sa come ripristinare il proprio stato da un memento.

Cos'e il Memento Pattern: definizione formale

Il Gang of Four definisce il Memento come un pattern comportamentale che "senza violare l'incapsulamento, cattura e esternalizza lo stato interno di un oggetto in modo che l'oggetto possa essere ripristinato a questo stato in seguito". Tre attori:

Originator: l'oggetto il cui stato deve essere salvato (es. l'editor). Ha metodi createMemento() e restore(Memento $m)
Memento: l'oggetto opaco che contiene lo snapshot dello stato. Espone il contenuto solo all'Originator.
Caretaker: gestisce la collection di memento (la history). Non accede mai al contenuto dei memento.

Esempio teorico: undo/redo in un editor grafico

Un editor grafico ha un canvas con forme (rettangoli, cerchi, linee). Ogni azione dell'utente (spostare una forma, cambiare colore, ridimensionare) modifica lo stato. Il sistema di undo funziona così:

Prima di ogni azione, il canvas chiama createMemento() che salva le posizioni, dimensioni e colori di tutte le forme
Il caretaker (un HistoryManager) pusha il memento nello stack di undo
L'utente preme Ctrl+Z: il caretaker poppa l'ultimo memento e chiama canvas->restore($memento)
Il canvas legge lo stato dal memento e si riporta alla configurazione precedente
Il memento poppato va nello stack di redo per permettere Ctrl+Y

Memento e serializzazione in PHP

In PHP, il Memento si implementa spesso tramite serializzazione. Il memento può essere un array associativo dello stato, un oggetto immutabile, o persino una stringa JSON. L'importante e che il contenuto sia opaco per il caretaker:

Array memento: createMemento(): array restituisce ['title' => $this->title, 'content' => $this->content]. Semplice ma espone la struttura.
Oggetto memento: una classe EditorMemento con proprieta private. Solo l'editor sa come leggerle. Più sicuro.
Memento criptato: lo stato viene serializzato e criptato. Anche se il caretaker accede al memento, non può leggerne il contenuto.

Memento vs Command per l'undo

Command con undo: ogni command sa come annullarsi. L'undo e inverso: esegue l'operazione opposta. Funziona se ogni operazione ha un inverso chiaro.
Memento: salva lo stato completo prima di ogni operazione. L'undo e ripristino: riporta allo stato salvato. Funziona anche quando l'operazione inversa non esiste o e ambigua.

Il Command e più efficiente (salva solo il delta), il Memento e più robusto (salva tutto). Per operazioni semplici e reversibili usa Command. Per stati complessi dove l'inverso e difficile da calcolare, usa Memento.

Quando usare il Memento Pattern

Usa il Memento quando devi implementare undo/redo e lo stato dell'oggetto e complesso
Usa il Memento quando vuoi salvare checkpoint/snapshot dello stato per recovery
Usa il Memento quando l'accesso diretto allo stato violerebbe l'incapsulamento
Non usare il Memento se lo stato e enorme e i memento consumano troppa memoria — considera il salvataggio incrementale
Non usare il Memento se l'operazione inversa e semplice e chiara: Command con undo e più leggero

Il Memento Pattern e il pattern della fotografia dello stato: cattura un istante, lo conserva, e lo ripristina quando serve. E il fondamento di ogni sistema di undo, versioning e recovery che rispetti l'incapsulamento degli oggetti.

👉 Leggi l'articolo completo su iadicola.it

Visitor Pattern: aggiungere operazioni senza modificare le classi

Dev-Iadicola — Fri, 10 Jul 2026 17:00:23 +0000

Il problema: nuove operazioni su classi chiuse

Hai una gerarchia di nodi AST (Abstract Syntax Tree) per un linguaggio di template: TextNode, VariableNode, IfNode, ForNode, IncludeNode. Devi aggiungere operazioni diverse su questi nodi: rendering HTML, compilazione in PHP, conteggio delle variabili usate, validazione della sintassi, pretty-printing. Se aggiungi un metodo per ogni operazione a ogni classe nodo, le classi esplodono di complessità. E peggio: ogni nuova operazione richiede di modificare tutte le classi nodo.

Il Visitor Pattern inverte la responsabilità: invece di aggiungere metodi ai nodi, crei un nuovo oggetto Visitor per ogni operazione. Il visitor "visita" ogni nodo e il nodo gli dice "sono un IfNode, trattami come tale". Questa tecnica si chiama double dispatch: il comportamento dipende sia dal tipo del visitor che dal tipo del nodo.

Cos'e il Visitor Pattern: definizione formale

Il Gang of Four definisce il Visitor come un pattern comportamentale che "rappresenta un'operazione da eseguire sugli elementi di una struttura di oggetti. Il Visitor permette di definire nuove operazioni senza cambiare le classi degli elementi su cui opera". La struttura:

Visitor: interfaccia con un metodo visit per ogni tipo di elemento (visitTextNode(TextNode $n), visitIfNode(IfNode $n))
ConcreteVisitor: implementa l'operazione specifica per ogni tipo di nodo (es. HtmlRendererVisitor, VariableCounterVisitor)
Element: interfaccia con un metodo accept(Visitor $v)
ConcreteElement: ogni nodo implementa accept() chiamando $v->visitXxx($this)

Il double dispatch spiegato

PHP (come Java e C#) supporta solo il single dispatch: il metodo chiamato dipende dal tipo dell'oggetto su cui viene chiamato, non dal tipo dei parametri. Il Visitor simula il double dispatch con due chiamate polimorfiche:

Il client chiama $node->accept($visitor) — primo dispatch basato sul tipo del nodo
Dentro accept(), il nodo chiama $visitor->visitIfNode($this) — secondo dispatch basato sul tipo del visitor

Il risultato: il comportamento dipende da entrambi i tipi. Un HtmlRendererVisitor che visita un IfNode produce HTML diverso da un VariableCounterVisitor che visita lo stesso IfNode.

Esempio teorico: analisi di un AST

Con il Visitor puoi aggiungere operazioni illimitate senza toccare i nodi:

HtmlRendererVisitor: trasforma l'AST in HTML. visitTextNode() restituisce il testo, visitIfNode() valuta la condizione e renderizza il branch corretto.
PhpCompilerVisitor: compila l'AST in codice PHP. visitIfNode() genera if ($condition) { ... }.
VariableCollectorVisitor: raccoglie tutte le variabili usate. visitVariableNode() aggiunge il nome alla lista.
SecurityAuditorVisitor: cerca pattern pericolosi. visitIncludeNode() verifica che il path non contenga input dell'utente non sanitizzato.

Ogni nuova operazione e una nuova classe Visitor. I nodi non cambiano mai. Questo e il potere del pattern: l'asse delle operazioni e aperto all'estensione.

Visitor nel mondo reale: Rector e PHPStan

Rector (il tool di refactoring automatico per PHP) e costruito interamente sul Visitor Pattern. Ogni regola di refactoring e un Visitor che attraversa l'AST del codice PHP. RenameClassRector visita i nodi di tipo Name e li rinomina. AddReturnTypeDeclarationRector visita i nodi ClassMethod e aggiunge i return type. Aggiungere una nuova regola significa creare un nuovo Visitor, senza toccare il parser o i nodi AST.

PHPStan usa lo stesso principio: ogni regola di analisi statica e un visitor che ispeziona nodi specifici dell'AST cercando pattern problematici.

Quando usare il Visitor Pattern

Usa il Visitor quando la struttura degli oggetti e stabile ma le operazioni cambiano spesso
Usa il Visitor quando vuoi aggiungere operazioni a classi che non puoi o non vuoi modificare
Usa il Visitor per separare algoritmi complessi dalle strutture dati su cui operano
Non usare il Visitor se la gerarchia di classi cambia spesso: ogni nuovo tipo richiede un nuovo metodo in tutti i visitor
Non usare il Visitor se hai 2-3 operazioni semplici: un metodo nella classe e più diretto

Il Visitor Pattern e il pattern della separazione operazione-struttura. Quando la struttura e stabile e le operazioni crescono, il Visitor evita di riaprire classi chiuse e mantiene ogni operazione in un'unita coesa e testabile.

👉 Leggi l'articolo completo su iadicola.it

Gestionale Magazzino, un software che può farti risparmiare soldi, tempo ed errori

Dev-Iadicola — Thu, 09 Jul 2026 17:00:21 +0000

Ogni magazzino vive di una domanda che si ripete dalla mattina alla sera: cosa è entrato, cosa è uscito, e dove si trova adesso? Sembra una cosa semplice, ma chiunque ci abbia lavorato sa che la realtà è fatta di terminali condivisi, operatori che si alternano, merce che esce prima di essere registrata, fornitori da rincorrere e inventari che non tornano mai del tutto.

Ho progettato questo gestionale partendo proprio da lì: non da un elenco astratto di funzioni, ma dai problemi concreti di chi il magazzino lo vive ogni giorno. Quasi ogni scelta dell'applicazione nasce da una frustrazione reale del lavoro quotidiano — e la cosa interessante è come è stata risolta. In questo articolo faccio un giro completo dell'applicazione, area per area, spiegando lungo il percorso perché funziona così.

Due ambienti, due esigenze diverse

L'applicazione è divisa in due mondi pensati per due modi di lavorare completamente diversi.

Il primo è il terminale dell'operatore: la postazione dove si scansiona, si carica, si scarica, svolgono resi e si conta. Deve essere veloce, a prova di errore, utilizzabile anche da chi non ha alcuna dimestichezza con i computer e magari ha i guanti addosso. Funziona benissimo su un tablet o uno smartphone.

Il secondo è il cruscotto del supervisore: la cabina di regia dove si tiene tutto sotto controllo, si analizzano i dati, si gestiscono le anagrafiche e si prendono le decisioni. Qui contano la visione d'insieme e il controllo, non la velocità di scansione.

La stessa applicazione, quindi, mostra cose diverse a persone diverse — e già questa è una scelta di progetto importante: ognuno vede solo ciò che gli serve davvero.

Il Software funziona sia su Desktop, Terminale e Smartphone

Per permettere la funzionalità ovunque ti trovi, senza spostarsi e dover andare da una zona per poter effettuare le operazioni.

Il terminale: il lavoro di tutti i giorni

Autenticazioni col PIN.

In un magazzino il computer (o il tablet) è uno solo e lo usano in tanti, a turno. Chiedere a ogni operatore di fare logout e login con email e password ogni volta che si avvicina alla postazione è una di quelle cose che, sulla carta, funziona — e nella pratica nessuno fa. Il risultato classico: lavorano tutti con lo stesso utente, e diventa impossibile sapere chi ha fatto cosa.

Qui la logica è diversa. Il terminale resta acceso alla prima autenticazione con email e password. Ma ogni operazione richiede un PIN personale di 4 cifre: l'operatore lo digita, fa il suo movimento, e quel movimento resta legato al suo nome per sempre. Il PIN "scade" dopo pochi minuti di inattività, così il sistema lo richiede di nuovo e non rischia mai di attribuire un'operazione alla persona sbagliata.

È un doppio orologio pensato apposta: uno lento, che tiene il dispositivo pronto all'uso senza costringere a riloggarsi di continuo; uno veloce, che garantisce la tracciabilità reale di ogni singolo gesto. Per chi entra e esce dalla postazione decine di volte al giorno cambia completamente l'esperienza, e per chi deve controllare cambia l'affidabilità dei dati.

Se un operatore passa lo smartphone a un altro operatore, per identificarsi deve digitare il PIN nella schermata.

Il design permette di effettuare lo scambio di utenti in modo veloce. Ogni utente ha un PIN personale che non deve condividere con nessun operatore.

Il carico: far entrare la merce

Quando arriva merce, l'operatore apre la schermata di carico, scansiona il codice a barre dell'articolo con laser o camera (o lo cerca per codice), inserisce le quantità e, se serve, il numero del documento di trasporto e il fornitore.

L'utente clicca Conferma, e la giacenza si aggiorna all'istante.

Ogni carico non è solo un "più uno" sul totale: genera un movimento registrato che conserva chi l'ha fatto, quando, quanto, da quale fornitore e con quale documento. Niente si perde, e tutto è ricostruibile, tutto rintracciabile e monitorato.

Lo scarico: l'app capisce da sola il perché

Quando la merce esce, può uscire per due motivi molto diversi: o viene venduta a un cliente, oppure viene consumata internamente dalla produzione. Sono due cose che vanno registrate in modo diverso, e di solito si chiede all'operatore di sceglierle da un menù. Ogni scelta manuale è un'occasione per sbagliare.

Così ho pensato a questo approccio:

Qui l'app lo capisce da sola, in base a chi sta lavorando. Un operatore "normale" scarica sempre verso un cliente; un operatore della produzione scarica sempre verso la produzione. Chi usa il sistema non deve decidere nulla: fa il suo lavoro e la classificazione corretta arriva in automatico. Il supervisore, che ha la visione completa, resta l'unico che può scegliere manualmente quando il caso lo richiede.

Meno scelte da fare significa meno errori — e numeri di fine mese che tornano. E se lo scarico supera la merce disponibile, il sistema lo segnala con un avviso, senza però bloccare il lavoro (più avanti spiego perché).

I resi: la merce che torna indietro

La merce non viaggia mai in una sola direzione. A volte un cliente restituisce qualcosa, a volte siamo noi a rispedire merce a un fornitore. La schermata dei resi gestisce entrambi i casi tenendoli ben distinti: il reso da cliente fa rientrare la merce in magazzino, il reso verso fornitore la fa uscire. Anche qui ogni movimento resta tracciato con il suo motivo, così l'inventario riflette sempre la situazione reale e non un'approssimazione.

La ricerca: trovare un articolo in un istante

Cercare un prodotto è l'azione più frequente in assoluto. Per questo la ricerca funziona sia per codice (incluso il codice a barre) sia per descrizione, ed è una ricerca testuale vera, che trova anche con parole parziali. Restituisce subito ciò che serve davvero a chi è in magazzino: dove si trova l'articolo, quanti pezzi sono disponibili e qual è il fornitore. Niente filtri complicati: si scrive e si trova. Da lì si apre la scheda di dettaglio dell'articolo con tutte le informazioni.

Creare un articolo "al volo", senza bloccare la merce

Capita spessissimo: arriva un bancale, l'operatore scansiona il codice e… quell'articolo non esiste ancora a sistema. La reazione naturale sarebbe mettere tutto in pausa, chiamare il responsabile, far creare la scheda — e nel frattempo la merce resta lì e il lavoro si ferma.

Con questo gestionale, se la funzione è abilitata, l'operatore può creare l'articolo sul momento, direttamente dalla schermata di carico, con un piccolo modulo veloce. L'articolo nasce subito ed è immediatamente disponibile per essere caricato. La merce entra, il lavoro non si ferma, e il supervisore completerà con calma i dettagli più tardi. È il supervisore stesso a decidere se concedere o meno questa possibilità, tramite un'impostazione.

Premessa: ogni articolo ha un codice EAN, pertanto scansionando il codice tramite fotocamera o tramite la pistola, è possibile riconoscere subito l'articolo. Questa funzionalità, infatti, permette di inserire articoli nuovi, mai arrivati in magazzino, per poter svolgere il lavoro con precisione e non avere duplicati, il software non permettere di inserire articoli con codice EAN duplicati.

L'inventario si conta "alla cieca"

Il momento dell'inventario fisico è quello in cui i conti dovrebbero finalmente tornare — ed è proprio quello in cui, spesso senza volerlo, si bara di più. Se l'operatore vede a schermo "a sistema risultano 100 pezzi", è umano che, contandone 98, finisca per scrivere 100 "tanto è quello giusto".

Qui durante la conta l'operatore non vede mai la quantità attesa: inserisce soltanto ciò che conta davvero, scansionando gli articoli uno a uno. Se prova a contare due volte lo stesso articolo nella stessa sessione, il sistema lo avvisa in modo chiaro. Il confronto con i dati di sistema avviene dopo, e solo dal lato del supervisore.

È una conta più onesta, perché elimina alla radice la tentazione di "aggiustare" il numero.

Il cruscotto del supervisore: governo e controllo

La dashboard: la fotografia del magazzino

Aprendo il cruscotto, il supervisore trova subito una dashboard con gli indicatori che contano: quanti articoli sono gestiti, quanti sono sotto la soglia minima e rischiano di esaurirsi, quanti movimenti ci sono stati nella giornata, quanti avvisi sono aperti. È la fotografia immediata dello stato di salute del magazzino, prima ancora di entrare nel dettaglio.

L'anagrafica articoli

Il cuore dei dati è l'anagrafica articoli, dove il supervisore gestisce tutto:

descrizione.
codice.
unità di misura.
ubicazione.
fornitore.
categoria di appartenenza e soglia minima (la scorta sotto la quale far scattare un avviso).

Qui si trovano anche le informazioni riservate, come prezzo di costo e prezzo di vendita, che gli operatori non vedono.

Etichettatura.

Dall'anagrafica è anche possibile generare e stampare le etichette con il codice a barre, così ogni articolo può essere scansionato in fase di carico, scarico e inventario. Un dettaglio pratico che chiude il cerchio tra dato digitale e merce fisica.

Le giacenze e i movimenti

La vista giacenze mostra tutte le scorte in un colpo d'occhio, con la possibilità di filtrare ed evidenziare gli articoli sotto soglia. È il "quanto ho" di tutto il magazzino.

La vista movimenti è invece il "cosa è successo": il registro completo e filtrabile di ogni carico, scarico, reso e rettifica, con data, operatore e articolo. È qui che, in caso di dubbio, si ricostruisce la storia esatta di un prodotto — chi lo ha toccato, quando e perché. È la memoria del magazzino.

Gli inventari

Le sessioni di inventario vengono aperte dal supervisore; gli operatori contano dal terminale, alla cieca come dicevo sopra. Quando la conta è completa, il supervisore confronta i numeri raccolti con quelli a sistema, vede le differenze e decide cosa fare. Se approva, è il sistema stesso a generare in automatico le rettifiche necessarie per allineare le giacenze — e ogni rettifica resta collegata all'inventario che l'ha prodotta. Niente correzioni "a mano" non tracciate.

Gli alert e le giacenze negative

Qui c'è una delle scelte più controcorrente dell'applicazione. Molti gestionali bloccano lo scarico se a sistema "non c'è abbastanza merce". Sembra prudente, ma nella pratica è il contrario: spesso la merce è già uscita fisicamente e semplicemente non è ancora stata registrata. Bloccare l'operazione costringe le persone a trovare scorciatoie pur di andare avanti, e il dato diventa ancora meno affidabile.

Questo sistema permette alla giacenza di scendere sotto lo zero, perché preferisce registrare la verità piuttosto che una finzione ordinata. Però, appena succede, fa scattare un avviso per il supervisore — esattamente come fa quando un articolo scende sotto la soglia minima. E gli avvisi sono intelligenti: non ripetono lo stesso allarme all'infinito, ma segnalano una sola volta finché la situazione non cambia davvero. Così le notifiche restano utili, invece di diventare rumore di fondo da ignorare.

Le anagrafiche di base e la gestione multi-sede

Attorno agli articoli ruotano le anagrafiche di supporto, tutte gestibili dal cruscotto: clienti, fornitori e ubicazioni (le posizioni fisiche dentro il magazzino). C'è inoltre la gestione delle sedi, pensata per chi ha più di un magazzino o deposito: le ubicazioni appartengono a una sede, così la stessa applicazione può seguire scorte distribuite su luoghi diversi.

Utenti, PIN e permessi

Il supervisore crea e gestisce gli utenti — nome, cognome, ruolo e PIN. Può assegnare un PIN, rigenerarlo in modo casuale, e il sistema lo aiuta a evitare doppioni suggerendo automaticamente un codice libero quando ne rileva uno già in uso.

Ma la parte più potente è la matrice dei permessi. Le regole di un magazzino cambiano nel tempo: oggi un certo ruolo può fare una cosa, domani no. Di solito modificare "chi può fare cosa" significa chiamare lo sviluppatore e aspettare un aggiornamento. Qui il supervisore ha una tabella che può modificare da solo, con qualche clic: decide quali ruoli possono creare articoli, approvare inventari, gestire utenti e così via. Le regole si adattano all'organizzazione senza bisogno di toccare il codice.

Le impostazioni e il diario delle attività

Dalle impostazioni il supervisore regola i comportamenti del sistema: i tempi di scadenza del PIN e della sessione, e se concedere agli operatori la creazione di articoli al volo. Sono le manopole che permettono di adattare l'app al ritmo del proprio magazzino.

Infine, ogni modifica importante — agli articoli, ai fornitori, ai PIN degli utenti — viene registrata in un diario delle attività: chi, cosa, quando. Una rete di sicurezza per quando serve capire come si è arrivati a una certa situazione. E quando i dati servono altrove, le viste principali si possono esportare in Excel per analisi, report o controlli.

Il filo conduttore di tutte queste scelte

Mettendo in fila queste decisioni, emerge una logica precisa. L'identificazione col PIN invece del login completo, la classificazione automatica dello scarico in base al ruolo, l'inventario alla cieca, le giacenze che possono andare in negativo invece di bloccare il lavoro: sono tutte facce della stessa idea.

La tecnologia deve adattarsi al modo in cui si lavora davvero in magazzino, non il contrario. Niente passaggi inutili imposti all'operatore, niente dati "puliti" ma falsi, niente regole rigide che costringono a inventarsi scorciatoie. Un gestionale che riduce gli errori non perché controlla di più le persone, ma perché chiede loro di pensare di meno alle cose che la macchina può capire da sola — e lascia il controllo, quello vero, a chi deve averlo.

Sotto il cofano, in breve

Senza entrare nel tecnico: l'applicazione gira interamente nel browser, quindi funziona da computer, tablet o smartphone senza installare nulla. La scansione dei codici a barre può usare sia un lettore fisico sia la fotocamera del telefono o del tablet. È costruita con tecnologie web moderne e ampiamente collaudate (l'ecosistema Laravel lato server, un'interfaccia reattiva lato utente), pensate per restare veloci e fluide anche con molti operatori che lavorano contemporaneamente sulla stessa postazione.

In sintesi: un software che mette d'accordo due esigenze che di solito litigano — la velocità di chi sta in mezzo alla merce e il controllo di chi deve rispondere dei numeri.

Il software è di proprietà del cliente. Pertanto ogni singolo software che produco sarà unico. Quest'articolo descrive un esempio di cosa è possibile costruire come software funzionali avanzati per la tua azienda.

Se sei interessato ad introdurre nuove tecnologie all'avanguardia, personalizzate e su misura per il tuo flusso di lavoro, contattami per capire come dovrà essere il tuo software, la struttura e tutto ciò che desideri che il software svolga.

👉 Leggi l'articolo completo su iadicola.it

Monolite modulare: la potenza del monolite con la struttura dei microservizi

Dev-Iadicola — Wed, 08 Jul 2026 17:00:12 +0000

Il falso dilemma: monolite o microservizi

Il dibattito "monolite vs microservizi" presenta una falsa dicotomia. Un monolite non deve essere per forza un Big Ball of Mud dove tutto dipende da tutto. E i microservizi non sono l'unico modo per avere separazione e modularita. Il monolite modulare e la terza via: un'applicazione deployata come un singolo artefatto, ma organizzata internamente in moduli con confini espliciti.

Shopify — una delle piattaforme e-commerce più grandi del mondo — ha scelto il monolite modulare con Rails. GitHub ha un monolite modulare Ruby. Basecamp idem. Non e una scelta per principianti: e una scelta architetturale consapevole che privilegia la semplicità operativa senza sacrificare la struttura.

Cos'e un modulo

Un modulo e una porzione dell'applicazione con:

Confini espliciti: un namespace dedicato, una directory propria. App\Modules\Orders\, App\Modules\Catalog\, App\Modules\Users\.
API pubblica: ogni modulo espone un'interfaccia limitata (un Service, un Facade) che gli altri moduli possono usare. Le classi interne sono private al modulo.
Database isolato (logicamente): ogni modulo possiede le proprie tabelle. Il modulo Orders non accede direttamente alle tabelle del modulo Catalog — passa attraverso l'API pubblica.
Comunicazione esplicita: i moduli comunicano tramite interfacce definite o eventi, non tramite import diretti di classi interne.

Esempio: un gestionale e-commerce modulare

Modulo Catalog: gestisce prodotti, categorie, prezzi. Espone CatalogService::getProduct(int $id) e CatalogService::checkAvailability(int $productId, int $qty).
Modulo Orders: gestisce ordini, carrello, checkout. Chiama CatalogService per verificare disponibilita, non accede alle tabelle prodotti direttamente.
Modulo Payments: gestisce pagamenti e fatturazione. Riceve eventi OrderPlaced dal modulo Orders.
Modulo Users: gestisce registrazione, profili, permessi. Gli altri moduli lo usano per autenticazione e autorizzazione.

Ogni modulo può evolvere indipendentemente. Il team che lavora sul Catalog non rischia di rompere gli Orders. Le dipendenze sono esplicite e unidirezionali.

Vantaggi rispetto al monolite classico

Confini chiari: sai dove finisce un modulo e dove inizia un altro. I refactoring sono localizzati.
Dipendenze visibili: se un modulo importa classi da un altro, e un code smell visibile — non un accoppiamento nascosto in una query SQL.
Team scaling: team diversi possono lavorare su moduli diversi con meno conflitti.
Migrazione futura: se un modulo diventa un collo di bottiglia, estrarlo in un microservizio e fattibile perché i confini sono già definiti.

Vantaggi rispetto ai microservizi

Deploy singolo: un artefatto, un server, un deploy. Nessun orchestratore, nessun service mesh, nessun distributed tracing.
Transazioni atomiche: le operazioni cross-modulo possono usare transazioni database. Nei microservizi servono saga e compensazioni.
Debugging semplice: un processo, uno stack trace, un log. Niente chiamate di rete da debuggare.
Costo operativo basso: un VPS da 20 EUR/mese invece di un cluster Kubernetes.

Quando scegliere il monolite modulare

Scegli il monolite modulare quando il team e piccolo-medio (2-10 sviluppatori) e la complessità e nel dominio, non nell'infrastruttura
Scegli il monolite modulare quando vuoi struttura e separazione senza il costo operativo dei microservizi
Scegli il monolite modulare come punto di partenza: puoi sempre estrarre un microservizio dopo, ma non puoi facilmente tornare indietro
Scegli i microservizi solo quando hai team grandi (50+), requisiti di scalabilità asimmetrica reali, e budget operativo adeguato

Il monolite modulare e la scelta pragmatica per la maggior parte dei progetti reali. Non e meno sofisticato dei microservizi — e più disciplinato: richiede la stessa cura nella definizione dei confini, senza la complessità della rete distribuita.

👉 Leggi l'articolo completo su iadicola.it

Da 11 a 4 secondi: come ho ottimizzato la velocità di un sito con render free tier

Dev-Iadicola — Tue, 07 Jul 2026 17:00:20 +0000

Primi aspetti.

Lunedì mattina. Apro il mio sito da una connessione 4G normale. Cronometro mentale. Uno, due, tre… nove… undici secondi. Undici secondi prima che la home sia utilizzabile.

Che dire*, potrei battere qualsiasi record.*

Dopotutto sto utilizzando render piano free e un database gratuito. Perché insomma, la qualità si paga. Si sa.

Il problema non è la pazienza dei nerd come me, abituati a tutto. Il problema è il cliente che cerca su Google "software gestionale su misura", clicca sul mio sito, e nei primi tre secondo decide se sono affidabile o meno. Se il sito è lento, la risposta è no. Chiude la tab. Apre quello dopo. E io ho perso un'opportunità senza nemmeno saperlo.

Il cliente giustamente non sa per quale motivo è lento. Io si, dietro a questa web app c'è un sistema di page building (simile a wix, quindi il DB non sta caricando quattro stringhe in croce con qualche FK, bensì un intero payload complesso).

Sappiamo dalle ricerche di Google che oltre il 50% degli utenti abbandona una pagina che impiega più di tre secondi a caricare. Sappiamo che la velocità è un fattore di ranking confermato. Eppure abbiamo tutti almeno un sito, da qualche parte, che fa undici secondi. Il mio era uno di quelli.

Cosa ho deciso di fare

Non un redesign. Non una nuova grafica. Non un cambio di tecnologia.

Volevo capire una cosa molto specifica: perché un sito relativamente semplice, scritto bene, riesce a essere così lento.

Qualcuno prenderebbe che per tirchieria non voglio spendere 7 o 24 euro al mese. (In effetti sì, tantovale che compro una VPS e ho tutto).

Ma non è solo questo il punto. Per me è diventata una sfida.

Voler ottimizzare un sistema che ha un database gratuito e un server con CPU 0.1

È questo quello che fa venire lo stimolo di sfida e dire "Sono bravo, perché sono riuscito ad ottimizzare l'impossibile"

Mi sono dato una regola. Niente intuizioni. Solo numeri.

Ho aperto gli strumenti di sviluppo del browser, ho misurato ogni richiesta, ho calcolato quanto tempo passava a scaricare cosa. Ho fatto la stessa misura prima di toccare anche solo una riga di codice, e l'ho ripetuta dopo ogni intervento. Senza misura prima e dopo non si ottimizza: si tira a indovinare.

Quello che ho trovato

Tre colpevoli, ognuno indipendente.

Il primo è il modo in cui il computer del server interpreta il codice. Per default, ogni richiesta ricomincia da zero come se fosse la prima della giornata. Esiste una scorciatoia che permette al server di ricordare il lavoro già fatto, ma è spenta nella configurazione standard. È un po' come avere un'auto e tenere il freno a mano tirato ad ogni semaforo verde.

Il secondo riguarda come il sito chiedeva al database le informazioni da mostrare. Per costruire un menu con tre livelli di profondità, il sito faceva una domanda al database per ogni voce, poi una per ogni sotto-voce, poi una per ogni sotto-sotto-voce. Risultato: decine di domande dove sarebbe bastata una sola, ben formulata, all'inizio.

Il terzo era il bagaglio del browser. Il sito caricava il codice di tutti i pulsanti, le icone, gli editor di testo che esistono nell'applicazione, anche se la pagina che stavi vedendo ne usava una decima parte. È come se andassi a fare la spesa portandoti dietro il barbecue, la moto del cuoco e l'intera collezione di pentole, ogni volta che esci di casa per prendere il latte.

Tre problemi, tre interventi.

Cosa ho cambiato, raccontato in italiano

Ho acceso la "memoria a breve termine" del server, ho implemtato un sistema di caching compesso. La prima volta che il sito risponde a una richiesta, ricorda il lavoro fatto. Le richieste successive partono già al 60% del percorso.

Ho ridotto il bagaglio del browser: il sito ora carica solo quello che serve alla pagina che stai vedendo, esattamente come quando entri in un'app sul telefono e si caricano solo le schermate che apri. In numeri, sono passato da 519 a 247 file caricati per visita. Più della metà in meno.

E ho aggiunto piccole cose collaterali. Le immagini ora viaggiano in un formato moderno che pesa il 40% in meno a parità di qualità visibile. Il browser viene istruito a tenere in cache locale tutto quello che non cambia, così alla seconda visita di un utente molti file non vengono nemmeno richiesti al server.

I risultati, senza retorica

Prima: 11,5 secondi di caricamento. 519 richieste. 1,84 megabyte di traffico.

Dopo: 4 secondi di caricamento. 247 richieste. 1,6 megabyte di traffico.

Il caricamento è sceso del 65%. Le richieste del 52%. Sono numeri misurati su un articolo reale del blog, con il browser pulito da cache, in produzione. Non sono il "best case" da slide commerciale: sono la realtà di un visitatore qualsiasi.

Quattro secondi non sono ancora il valore che voglio. L'obiettivo è sotto il secondo e mezzo. Ma sono già un altro mondo rispetto a undici secondi, e l'effetto sul tasso di rimbalzo si vedrà nei prossimi trenta giorni di analytics.

Perché un sito veloce non è una pignoleria tecnica

Tre motivi, uno per ogni stakeholder.

Per chi vende, il sito veloce è una promessa implicita: dice "questa azienda lavora con cura". Se hai due fornitori sulla stessa fascia di prezzo e uno carica in tre secondi e l'altro in dieci, su quale clicchi il pulsante "richiedi preventivo"?

Per chi guarda le metriche di marketing, la velocità è una leva diretta su due numeri. Il primo è la posizione su Google: i Core Web Vitals, da anni, sono parte del ranking factor ufficiale. Un sito veloce sale, un sito lento scende. Il secondo è il tasso di conversione: ogni secondo guadagnato sui tempi di caricamento si traduce, sui dati pubblici di Amazon e Walmart, in qualche punto percentuale di vendite in più.

Per chi gestisce l'infrastruttura, ottimizzare significa anche pagare meno.

Server che lavorano meno, traffico che pesa meno, immagini che occupano meno spazio.

È una linea di costo che non si vede sul P&L finché non la guardi, e quando la guardi capisci che potevi risparmiare.

Il bottleneck che resta

Onestà: dei 4 secondi attuali, circa 3 sono tempo che il server impiega a generare la risposta. Solo 1 secondo è effettivo download e visualizzazione. Significa che il prossimo round di ottimizzazione non passa più dal frontend: passa da capire perché il backend ci mette 3 secondi.

Ho già installato gli strumenti per misurarlo. Quando avrò i numeri, scriverò il secondo episodio di questa cronaca, con prima e dopo, esattamente come questo.

Cosa porti via da questo articolo

Se la velocità del tuo sito non l'hai mai misurata, fallo oggi. Apri pagespeed.web.dev, incolla l'URL della home, leggi il punteggio. Se è verde, congratulazioni. Se è giallo o rosso, hai uno strumento concreto in mano: un punto di partenza misurabile, e una conversazione da aprire con chi gestisce il tuo sito.

Se i numeri non ti piacciono e vuoi un audit indipendente che ti dica con onestà cosa si può migliorare, dove, e con quanto sforzo, scrivimi tramite il form contatti.

Lavoro per progetti su misura, partendo sempre dai numeri reali e mai dalle metriche di vanity.

Il secondo episodio arriva quando avrò abbattuto i tre secondi di backend. Stay tuned.

👉 Leggi l'articolo completo su iadicola.it

Event Sourcing: la storia completa del tuo sistema

Dev-Iadicola — Mon, 06 Jul 2026 17:00:22 +0000

Il problema: lo stato corrente cancella la storia

Un conto corrente bancario ha un saldo di 1.500 EUR. Questo e lo stato corrente. Ma come ci e arrivato? Stipendio di 2.000, affitto di 800, spesa di 200, rimborso di 500. In un sistema tradizionale, il database contiene solo il saldo — la storia e persa. Se un'operazione e stata applicata per errore, non puoi ricostruire la sequenza. Se vuoi sapere qual era il saldo il 15 del mese scorso, devi averlo salvato esplicitamente.

L'Event Sourcing inverte il modello: invece di salvare lo stato corrente e aggiornarlo, salvi ogni evento che ha modificato lo stato. Lo stato corrente si ricostruisce riproducendo (replaying) gli eventi in sequenza. Il saldo e il risultato di: Deposited(2000) → Withdrawn(800) → Withdrawn(200) → Deposited(500) = 1500.

Come funziona: Event Store e Proiezioni

Event Store

Gli eventi vengono salvati in un event store — una tabella append-only dove ogni riga e un evento immutabile con: ID, aggregate ID, tipo evento, payload (dati dell'evento), timestamp, versione. Gli eventi non vengono mai modificati o cancellati. Sono fatti storici: "e successo questo, in questo momento, con questi dati".

Proiezioni (Read Models)

Lo stato corrente viene costruito da proiezioni: funzioni che ascoltano gli eventi e aggiornano viste materializzate ottimizzate per la lettura. Una proiezione "saldo corrente" somma depositi e sottrae prelievi. Una proiezione "movimenti mensili" raggruppa gli eventi per mese. Una proiezione "clienti con saldo negativo" filtra e aggrega.

Il potere delle proiezioni e che puoi crearle retroattivamente. Se domani serve un report che non esisteva ieri, crei una nuova proiezione che riproduce tutti gli eventi storici e costruisce il report dall'inizio dei tempi. Con un database tradizionale, i dati storici sono persi.

Esempio teorico: gestione ordini

Un ordine e-commerce attraversa molti stati. Con Event Sourcing, ogni transizione e un evento:

OrderCreated { items: [...], customer_id: 42 }
PaymentReceived { amount: 150.00, method: "card" }
OrderShipped { tracking: "IT123456", carrier: "GLS" }
OrderDelivered { signed_by: "Mario Rossi" }

Lo stato corrente dell'ordine si ricostruisce riproducendo gli eventi. Ma hai anche: audit trail completo (chi ha fatto cosa e quando), la possibilita di ricostruire lo stato a qualsiasi punto nel tempo, e proiezioni dedicate per dashboard, analytics e reporting.

Event Sourcing + CQRS: la combinazione naturale

Event Sourcing si combina naturalmente con CQRS: i Command scrivono eventi nell'event store. Le Query leggono dalle proiezioni. I due percorsi sono completamente separati e ottimizzati indipendentemente. Le proiezioni possono usare strutture dati diverse (tabelle SQL, documenti MongoDB, indici Elasticsearch) a seconda delle esigenze di lettura.

I costi reali

Complessità: il modello mentale e radicalmente diverso dal CRUD. Il team deve pensare in termini di eventi, non di stato.
Eventual consistency: le proiezioni non sono aggiornate istantaneamente. Tra la scrittura dell'evento e l'aggiornamento della proiezione c'e un ritardo (spesso millisecondi, ma non zero).
Schema evolution: gli eventi sono immutabili. Se il formato di un evento cambia, servono strategie di versioning (upcasting).
Storage: gli eventi si accumulano nel tempo. Un sistema con milioni di transazioni al giorno genera terabyte di eventi. Servono strategie di archiviazione e snapshot.

Quando usare Event Sourcing

Usa Event Sourcing quando l'audit trail completo e un requisito di business (finanza, sanita, legale)
Usa Event Sourcing quando devi poter ricostruire lo stato a qualsiasi punto nel tempo
Usa Event Sourcing quando le proiezioni retroattive hanno valore di business
Non usare Event Sourcing per CRUD semplici: il costo di complessità non si giustifica
Non usare Event Sourcing se il team non ha esperienza con sistemi event-driven: la curva di apprendimento e ripida

Event Sourcing non e un'architettura per tutti i progetti: e una strategia di persistenza per domini dove la storia ha valore. Quando lo stato corrente non basta e serve sapere come ci sei arrivato, Event Sourcing trasforma il database da una fotografia a un film completo.

👉 Leggi l'articolo completo su iadicola.it