RDBMS in contesti DDD

Se siete dei DBA vi consiglio caldamente di ignorare questo post o di leggerlo ben ancorati ad una sedia, magari sorseggiando della potente camomilla.

Quello che voglio esporre oggi è il mio modo di vedere un database relazionale in un contesto DDD dove un team di persone lavorano insieme allo stesso progetto.
Ok, quello che esporrò durante il post in realtà è un concetto molto semplice: il DB c’è perchè la memoria RAM dei nostri server è volatile e dobbiamo salvare su disco i nostri dati, quindi, dato che il nostro obbiettivo è persistere dei dati, il database non è altro che il contenitore che mi permette di fare questa cosa punto.

Stored Procedure

Le stored procedure sono una gran bella cosa, resta il fatto che scriverle necessita comunque di un investimento di tempo, quindi il concetto in un contesto DDD è: dato che il nostro utente finale ha accesso ad una GUI dove potrà fare ben poche cose, le quali passeranno per un service layer e a sua volta per un business layer e ancora ad un data layer… mi chiedo se il rischio di inserire dati incoerenti è veramente così tangibile come in una applicazione monolitica.
Inoltre, inserendo anche se in minima parte, della logica all’interno di una sp, rischierei di non riuscire ad automatizzarne i test, rischierei di far fatica a trovare un bug, oltre a dover in qualche modo fare delle scelte su cosa mettere e dove, dividersi i lavori con chi sviluppa il DB ecc…

Trigger

Per i trigger è valido lo stesso discorso delle stored procedure, il mio obbiettivo in DDD è centralizzare le logiche in un Domain, non sparpagliare logiche sui vari layer.

Readable Fields

Il database deve essere “masticabile” dal team, esempio: mettere il campo CliFor che se è uguale a C allora si intende cliente, se è uguale a F allora è un fornitore, è corretto?
Ok, magari le performance con questa analisi possono essere migliori, ma siamo realmente sicuri che in un team, ognuno si ricordi o sappia sempre cosa siano quelle C ed F?
Ad intuito potrei dire dire di si, ma se io avessi estremizzato e messo un campo di nome “type” con valori 1 e 2, quanto avrei impiegato prima di capire la corrispondenza di 1 e quella di 2?
La domanda che ci dobbiamo porre in questi casi è: le performance al giorno d’oggi sono davvero un problema? La mia risposta è, nella maggior parte dei casi, NO.

Data-forma-mentis

DDD è un modello orientato agli oggetti, RDB è invece un modello orientato ai dati, il problema è proprio questo.
In particolare il problema è la DUPLICAZIONE dei dati, a cui siamo abituati a pensare come IL MALE.
Don’t Repeat Yourself (DRY, anche conosciuto come “Single Point of Truth”) è un principio secondo il quale l’informazione non debba essere ripetuta e ridondante e non si debba esprimere lo stesso concetto più di una volta, specie se in forma diversa.
In DDD ragioniamo per aggregate e cambi di stato delle entity mentre nel DB, quello che facciamo è creare meno tabelle possibili e interconnesse al massimo con i constraint per evitare la duplicazione dei dati.
Ok, duplicare è un male, ma seppur questo assunto sia sempre valido per i “behaviour”, vale lo stesso per i dati?
Prendiamo per esempio, un ordine.
Un ordine è il nostro aggregate nel domain e avrà diversi stati (creato, spedito, ricevuto, cancellato ecc…), come modellerebbe un ordine un DBA?
Immagino creando una tabella ordini, una righe ordini, e nella tabella ordini inserire campi adhoc, per determinare lo stato dell’ordine, ad esempio: se il campo DataSpediz è uguale a null allora è da spedire altrimenti è stato spedito il giorno tot.
Insomma, non centra nulla con la persistenza pura dei dati, per arrivare a determinare lo stato dell’ordine devo eseguire della logica, logica che può cambiare se qualcuno “tocca” qualcosa e magari può crearmi dei problemi.
Qui in questo caso, IMVHO, la tabella ordini andrebbe duplicata per gli N stati che un ordine può assumere e lasciare che il Domain decida come gestire i record, allentando la frizione del concetto DRY.

Conclusioni

Ricordo a tutti che quanto detto è un modo del tutto personale di approcciare DDD, quindi non è mia intenzione fare da guida ad altri ne tanto meno escludere che stia sparando cavolate.
Ad ogni modo il concetto finale già detto all’inizio è, modelliamo il nostro DB come se fosse un accessorio del nostro domain, sbattiamoce dei tecnicismi di SQL Server piuttosto che Oracle ecc…
Cerchiamo ad ogni modifica al DB di farci le seguenti domande:
Posso farlo in modo che sia ancora più leggibile?
Posso farlo anche con altri db systems senza impazzire (se ci interessa la portabilità)?
Sono sicuro che non sto facendo questa cosa solo per evitare che il mio dato si duplichi?
Eventualmente, questa duplicazione avrebbe dei costi molto alti?

Rispondi

Leggi articolo precedente:
Disaccoppiare con un’infrastruttura Enterprise Service Bus

Un Enterprise Service Bus (ESB) è un'infrastruttura software che fornisce servizi di supporto ad architetture SOA complesse. <>

Chiudi