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:
Productcon peso, dimensioni, posizione scaffale, quantità -
Contesto Ordini:
OrderLinecon prodotto riferito per ID, quantità ordinata, prezzo al momento dell'ordine -
Contesto Fatturazione:
InvoiceLinecon descrizione, importo, aliquota IVA -
Contesto Spedizione:
Parcelcon 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.
Top comments (0)