DDD

CSDD–programming pornography

Gian Maria Ricci — Mon, 31 Oct 2011 11:33:51 GMT

In realtà la frase “programming pornography” la ho sentita da Greg Young durante il DDD Day, ma si allinea ad uno degli altri importanti concetti che sono emersi durante il campus DDD. In questo caso Alberto ha sottolineato il fatto di come nelle discussioni nei gruppi DDD troppo spesso si parla di tecnicismi e nella maggioranza dei casi si parla quasi sempre di ORM.

Il concetto in questo caso è che il vantaggio maggiore del DDD è il metodo di approcciare il problema, ovvero cercare di sviscerare le logiche ed individuare le Entità che possono meglio modellare le logiche del dominio reale. Naturalmente, dato che l’approccio è principalmente teso alla “scoperta”, il primo modello difficilmente sarà quello giusto, per cui è necessario per lo meno nelle fasi iniziali farne più di uno e scegliere quello che “ci soddisfa maggiormente”, capendo poi che molto probabilmente verrà comunque cambiato. Il vero valore quindi è nella stesura del modello e non nella sua implementazione, per cui bisognerebbe cercare di dedicare più tempo alla modellazione, cercando di non farci “traviare” dagli aspetti tecnici.

Purtroppo questo accade perché la community DDD è giovane, non esiste ancora da nessuna parte una “reference implementation” e difficilmente ne esisterà mai una, per questo bisogna accettare che in realtà il vero valore è nel modello e la realizzazione tramite codice è “programming pornography”, che probabilmente verrà rifatta per ogni progetto. Debbo dire che io sono il primo che lamento la mancanza in rete di “codice di esempio”, che possa aiutare a parlare concretamente di DDD con del codice sottomano, ma negli ultimi tempi sto realizzando che la parte implementativa è sicuramente importantissima, ma troppo spesso diventa dominante, quando invece la parte dominante dovrebbe essere il modello e la parte implementativa un corollario.

Questo coincide con un raffreddamento del mio entusiasmo sugli ORM, che inizio a considerare talvolta degli “antipattern” che troppo spesso spostano la nostra attenzione lontano dalla ciccia. Nondimeno avere in rete delle implementazioni concrete e funzionanti di Event Sourcing, Domain Events e quant’altro, sicuramente gioverebbe a tutto il movimento, perché permetterebbe di poter dire “ok mi concentro nel modello, dato che comunque un paio di implementazioni con cui iniziare ad implementare il modello ci sono”.

Gian Maria.

CSDD–Aggregate root

Gian Maria Ricci — Tue, 18 Oct 2011 18:01:09 GMT

Dopo la prima lettura del libro di Evans (e vi assicuro che vale la pena di leggerlo almeno due volte), uno dei principi che maggiormente ho apprezzato è senza dubbio quello dell’AGGREGATE ROOT e degli AGGREGATES in generale.

An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.

L’importanza di questo pattern è la stessa del BOUNDED CONTEXT perchè porta alla riduzione della complessità, limitando la possibilità di instaurare relazioni tra gli oggetti. Il livello di granularità di frazionamento di questo pattern è minore del BOUNDED CONTEXT e può costituire essenzialmente un ulteriore livello di suddivisione. Partiamo quindi dal problema che vogliamo evitare, che è essenzialmente lo stesso mostrato nel post precedente.

In domini complessi infatti, un singolo BOUNDED CONTEXT può essere molto complesso ed è deleterio permettere ad ogni oggetto di poter dialogare direttamente con qualsiasi altro oggetto nello stesso contesto, perchè si rischia di ricadere in un contesto cosi interconnesso che è poco gestibile. In pratica un AGGREGATE non è altro che un insieme di oggetti che rappresenta un’entità ben definita del dominio e l’AGGREGATE ROOT è l’oggetto che incapsula tutto il gruppo e ne costituisce la barriera di accesso. Non esiste una regola generale per individuare un AGGREGATE, ma in generale, se in un contesto abbiamo oggetti che da soli non hanno molto significato, ma acquistano significato presi assieme, questo potrebbe molto facilmente essere un aggregato.

Se facciamo un esempio nel dominio di un ipotetico gioco di ruolo, potremmo dire che un Guerriero è composto da un insieme di oggetti come ad esempio le caratteristiche (forza, intelligenza, presenza, etc), dalle abilità (uso delle armi, salto, corsa, etc) e tutto questo insieme di oggetti costituisce la rappresentazione in questo BOUNDED CONTEXT dell’entità Guerriero. In questo caso infatti una caratteristica ad esempio non ha alcun senso se non associata al concetto di Guerriero e quindi ne costituisce una parte.

Il primo vantaggio del’AGGREGATE è quello di presentare all’esterno un unico punto di contatto, chiamato AGGREGATE ROOT, in particolare esiste un principio che permette ad un repository di gestire solamente gli aggregate root. L’AGGREGATE ROOT diviene quindi un ulteriore astrazione che favorisce il concetto di incapsulamento. Cosi come una classe protegge il suo stato interno grazie ai metodi e fornisce una interfaccia o contratto che implementa la comunicazione con l’esterno, un’AGGREGATE ROOT incapsula una serie di oggetti che rappresentano l’aggregato..

Grazie a questa astrazione è quindi possibile ridurre il numero di interconnessioni tra oggetti, perché queste ultime sono limitate agli AGGREGATE ROOT.

L’aspetto del salvataggio è particolarmente importante, abbiamo infatti due assunti precisi

1) Solo gli aggregate root possono essere gestiti tramite repository
2) Ogni aggregato ha il suo repository per la gestione della persistenza.

Questo significa che se un particolare aggregato è cosi complesso che ci viene facile salvarlo su un NoSQL, possiamo farlo senza problemi, altri aggregati potrebbero per esempio salvarsi semplicemente serializzando su disco, oppure chiamando un servizio esterno che li persiste on the cloud. Questa affermazione solitamente scatena ogni sorta di obiezioni, primo tra tutti il dire “come faccio I report?”, quando in una interfaccia debbo mostrare dei dati che vengono da aggregati differenti che prestazioni avrò se debbo prendere I dati da sorgenti eterogenee e poi magari aggregare in memoria? Purtroppo come in molte aree del DDD non esiste un’unica risposta, e dobbiamo capire se il vantaggio che abbiamo magari usando un NoSQL non ci fa perdere da altre parti.

Una soluzione possibile è CQRS + DOMAIN EVENTS, ogni cambiamento significativo di un AGGREGATE ROOT genererà infatti un evento di dominio, che dovrà essere gestito da un Handler apposito che terrà aggiornate le classiche viste readonly su cui fare le query. Alcuni db NoSQL come raven hanno dei plugin che permettono automaticamente di tenere sincronizzato un database SQL con alcune proprietà degli oggetti salvati. L’obiettivo è quello di cercare di racchiudere la complessità del problema nel dominio e non nell’infrastruttura che ci sta attorno (leggasi ORM). La morale è, se debbo fare carte false per persistere una gerarchia complessa con un ORM, solo perché “tutto il resto è persistito con un ORM”, probabilmente non abbiamo necessariamente preso la strada giusta e vale la pena di pensare se un AGGREGATE o un intero BOUNDED CONTEXT non possano usare strategie differenti di persistenza.

alk.

Considerazioni sul campus #CSDDD

Gian Maria Ricci — Tue, 06 Sep 2011 07:32:32 GMT

Questo fine settimana, il sottoscritto ed altre strane persone :), si sono chiuse in un agriturismo marchigiano e sotto la guida di ZioBrando hanno passato tutto il fine settimana a parlare di DDD. (trovate alcune foto nel mio profilo facebook).

L’esperienza è stata decisamente positiva, diciamo che mi sono convinto ancora di più che il DDD sia applicabile in molti più scenari di quello che pensavo. L’unica pecca è stata l’avere scritto poco codice e sostanzialmente ce ne siamo andati con ancora alcuni dubbi a livello “implementativo”, del tipo, come faccio cosa? Un handler di un domain event ha senso che sia in un aggregate?, e cosi via, ma comunque moltissime idee si sono chiarite.

I concetti base sono che: è fondamentale avere tanta carta su cui tracciare le proprie idee e avere voglia di esplorare per capire il dominio. Nei prossimi giorni, tempo permettendo :), cercherò di enunciare quelli che per me sono i concetti più importanti che abbiamo appreso nel campus, che potete comunque vedere anche in questa foto, che rappresenta il nostro learning tree del campus.

Stay tuned

Gian Maria.

Repository, altre considerazioni

Gian Maria Ricci — Fri, 28 Sep 2007 13:00:07 GMT

In un thread su guisa si è un po parlato di costruttori e persistenza. Sempre continuando il discorso del repository, volevo dare la mia opinione su come i costruttori si legano al repository. Come anche Fowler dice, la costruzione di un oggetto non è pertinenza del repository, ma il repository ha il seguente scopo

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

Per questa ragione il ciclo di vita di un oggetto è il seguente: chiamando uno dei costruttori o un metodo factory si crea una nuova istanza, questa nuova istanza è transiente per utilizzare la notazione di Nhibernate. A questo punto il repository entra in gioco perché presenta all'utente una interfaccia collection-like, ovvero si comporta come un contenitore in memoria, internamente il repository dialoga con il layer di persistenza e quindi lo stato dell'oggetto diventa persistente, ma per il chiamante tutto questo è completamente trasparente. Una delle convenienze dei repository è che si possono creare repository solamente per le root degli aggreati in modo da impedire all'utilizzatore di andare a ricostruire direttamente oggetti interni di un aggretago. Una discussione approfondita è comunque fatta nel libro di Evans. Personalmente però non amo l'utilizzo di costruttori o metodi factory per effettuare la reconstitution di un oggetto, ma preferisco accentrare il tutto nel repository.

Alk.

Repository e LINQ

Gian Maria Ricci — Fri, 10 Aug 2007 15:10:00 GMT

Premesso che sono alle prime armi con LINQ, in questo post faccio vedere una prima ipotesi di come il nostro repository possa dare funzionalità di query per LINQ grazie al progetto LINQ to NHIbernate. Alk.

Repository – Fluent Query Interface

Gian Maria Ricci — Tue, 07 Aug 2007 12:52:00 GMT

Quarta parte degli articoli sul repository.

Repository non generico

Gian Maria Ricci — Mon, 06 Aug 2007 15:47:00 GMT

Terza parte della serie di post su come realizzare un repository pattern.

Gestire un repository Generico [1]

Gian Maria Ricci — Sun, 05 Aug 2007 08:05:00 GMT

seconda parte del post sull'argomento "repository pattern" Alk.

Gestire un repository generico

Gian Maria Ricci — Sun, 05 Aug 2007 08:01:00 GMT

Prima parte di una serie di post sull'argomento "repository Pattern" In relazione ad un thread aperto su guisa. (http://www.guisa.it/forums/1258/ShowThread.aspx#1258) Alk.