Aggregati, repository e factory
Proteggete gli invarianti con gli aggregati e rendeteli persistenti in modo ordinato.
Aggregati, repository e factory è una lezione PHP Academy gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento PHP Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso PHP Academy include 4 lezioni in totale.
Proteggere gli invarianti
Una volta definite entità e oggetti valore, servono alcuni pattern per mantenere coerenti i gruppi che li compongono e per gestirne la persistenza in modo corretto. Il DDD propone tre pattern tattici: l’Aggregato, che definisce un confine di coerenza; il Repository, un’astrazione della persistenza simile a una collezione; e la Factory, dedicata alla costruzione complessa. Questa lezione mostra come collaborano in PHP.
Che cos’è un aggregato
Un aggregato è un gruppo di entità e oggetti valore trattato come un’unica unità per le modifiche ai dati. Un’entità è la radice dell’aggregato, ovvero l’unico membro a cui il codice esterno può fare riferimento. Tutte le modifiche passano dalla radice, che applica gli invarianti dell’aggregato. L’aggregato è anche il confine transazionale: viene caricato e salvato in modo atomico.
La radice protegge l’intero aggregato
Il codice esterno non accede mai direttamente ai membri interni. Per aggiungere una riga d’ordine si chiama un metodo della radice, che valida i dati e mantiene la coerenza, ad esempio dei totali e dei limiti. In questo modo gli invarianti restano concentrati in un unico punto.
<?php
final class LineItem {
public function __construct(
public readonly string $sku,
public readonly int $qty,
public readonly int $unitCents
) {}
public function subtotal(): int { return $this->qty * $this->unitCents; }
}
final class Order { // Aggregate Root
/** @var LineItem[] */
private array $items = [];
public function __construct(public readonly string $id) {}
public function addItem(string $sku, int $qty, int $unitCents): void {
if ($qty < 1) { throw new DomainException('qty must be >= 1'); }
$this->items[] = new LineItem($sku, $qty, $unitCents);
}
public function total(): int {
return array_sum(array_map(fn(LineItem $i) => $i->subtotal(), $this->items));
}
}
$o = new Order('o1');
$o->addItem('A', 2, 500);
$o->addItem('B', 1, 300);
echo $o->total(), PHP_EOL; // 1300
Progettare aggregati piccoli
Un errore frequente consiste nel creare aggregati troppo grandi, come un Order che possiede anche l’intero grafo di Customer. Regole pratiche:
- Mantenga gli aggregati piccoli; faccia riferimento agli altri aggregati tramite il loro id, senza conservare l’oggetto.
- Una transazione dovrebbe modificare un solo aggregato; per coordinare più aggregati si utilizzino gli eventi di dominio.
- Il confine è definito dagli invarianti che devono essere sempre rispettati.
Fare riferimento tramite id
L’ordine memorizza un oggetto valore customerId, non un’entità Customer. In questo modo il confine di coerenza resta ristretto e si evita di caricare grafi di oggetti enormi. La coerenza tra aggregati diventa eventuale e viene gestita tramite eventi, invece che tramite un’unica transazione gigantesca.
<?php
final class CustomerId {
public function __construct(public readonly string $value) {}
}
final class Order {
public function __construct(
public readonly string $id,
public readonly CustomerId $customerId // reference, not object
) {}
}
$order = new Order('o1', new CustomerId('cus_99'));
echo $order->customerId->value, PHP_EOL;
Il contratto del Repository
Un Repository offre l’illusione di una collezione in memoria di radici di aggregato. Il dominio dipende soltanto dall’interfaccia; l’implementazione, basata su Doctrine, PDO o sulla memoria, risiede nel livello infrastrutturale. I repository gestiscono aggregati interi, mai righe parziali.
<?php
interface OrderRepository {
public function ofId(string $id): ?Order;
public function save(Order $order): void;
public function nextIdentity(): string;
}
Un’implementazione in memoria
Un repository in memoria è prezioso per eseguire rapidamente unit test senza un database. Poiché il dominio dipende dall’interfaccia, è possibile sostituire liberamente le implementazioni: è la Dependency Inversion in azione.
<?php
interface OrderRepository {
public function ofId(string $id): ?object;
public function save(object $order): void;
public function nextIdentity(): string;
}
final class Order { public function __construct(public readonly string $id) {} }
final class InMemoryOrderRepository implements OrderRepository {
private array $store = [];
public function ofId(string $id): ?object { return $this->store[$id] ?? null; }
public function save(object $order): void { $this->store[$order->id] = $order; }
public function nextIdentity(): string { return 'o_' . bin2hex(random_bytes(4)); }
}
$repo = new InMemoryOrderRepository();
$repo->save(new Order('o1'));
var_dump($repo->ofId('o1') !== null);
Il Repository non è un DAO
Un Repository non è un DAO CRUD generico. Espone query significative per il dominio, come findOverdueOrders(), e ricostruisce aggregati completi con i relativi invarianti intatti. Nasconde deliberatamente i dettagli di SQL e dell’ORM, così il dominio resta indipendente dalla persistenza. Eviti di introdurre nel dominio query builder o metodi generici come save($anyEntity).
Factory per la creazione complessa
Quando la costruzione di un aggregato implica una logica reale, come la generazione dell’identità, l’assemblaggio degli oggetti valore e l’applicazione degli invarianti al momento della creazione, la si sposti in una Factory, cioè in una classe dedicata o in un costruttore statico denominato. In questo modo il costruttore dell’entità resta essenziale e le regole per una creazione valida vengono centralizzate.
<?php
final class Order {
private function __construct(
public readonly string $id,
public readonly string $customerId
) {}
public static function place(string $customerId): self {
if ($customerId === '') { throw new DomainException('customer required'); }
return new self('o_' . bin2hex(random_bytes(4)), $customerId);
}
}
$order = Order::place('cus_1');
echo $order->id, PHP_EOL;
Come collaborano
Il flusso tipico in un servizio applicativo è il seguente:
- Una Factory, o un costruttore denominato, crea un aggregato valido.
- I metodi della radice dell’aggregato applicano gli invarianti durante l’utilizzo.
- Un Repository persiste e in seguito ricostruisce l’intero aggregato.
Il servizio applicativo coordina queste operazioni all’interno di una transazione per aggregato e dipende soltanto dalle interfacce.
Applicare un invariante dell’intero aggregato
Il vero valore della radice consiste nell’applicare gli invarianti che coinvolgono più membri. In questo caso l’ordine rifiuta una riga d’ordine se questa facesse superare al totale il limite di credito, una regola che nessun singolo LineItem potrebbe applicare da solo. Poiché tutte le modifiche passano dalla radice, la regola non può mai essere aggirata.
<?php
final class Order {
private array $items = [];
public function __construct(
public readonly string $id,
private int $creditLimitCents
) {}
public function addItem(int $cents): void {
if ($this->total() + $cents > $this->creditLimitCents) {
throw new DomainException('Exceeds credit limit');
}
$this->items[] = $cents;
}
public function total(): int { return array_sum($this->items); }
}
$o = new Order('o1', 1000);
$o->addItem(600);
try { $o->addItem(600); } catch (DomainException $e) { echo $e->getMessage(), PHP_EOL; }
echo $o->total(), PHP_EOL; // 600
Verifica rapida
Progettazione degli aggregati.
Riepilogo
Ha imparato a proteggere gli invarianti e a gestire correttamente la persistenza. Gli aggregati definiscono un confine di coerenza e transazionale: vengono modificati solo tramite la loro radice e restano piccoli facendo riferimento agli altri aggregati tramite id. I Repository presentano le radici degli aggregati come una collezione accessibile tramite un’interfaccia di dominio, nascondendo ORM e SQL e consentendo l’uso di sostituti in memoria per i test. Le Factory centralizzano la creazione complessa che applica gli invarianti. Insieme, mantengono coerente il modello di dominio e indipendente dai dettagli di persistenza.
Domande Frequenti
La lezione «Aggregati, repository e factory» è gratuita?
Sì — il testo completo di «Aggregati, repository e factory» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso PHP Academy, passa a CoddyKit PRO. Il corso PHP Academy include 4 lezioni in totale.
Cosa imparerò in «Aggregati, repository e factory»?
Proteggete gli invarianti con gli aggregati e rendeteli persistenti in modo ordinato. Eserciti PHP Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare PHP Academy?
Non è richiesta alcuna esperienza precedente. PHP Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «Aggregati, repository e factory»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione PHP Academy?
Sì. Ogni lezione PHP Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Blocchi fondamentali del DDD: entità e oggetti valore
- Aggregati, repository e factory
- Eventi e servizi di dominio
- Bounded context e context mapping