La progettazione guidata dal dominio è un modello anti-SQL?

Mi sto tuffando nel design guidato dal dominio (DDD) e mentre ci approfondisco ci sono alcune cose che non capisco. A quanto ho capito, un punto principale è quello di dividere la logica di dominio (Business Logic) dall'infrastruttura (DB, file system, ecc.).

Quello che mi chiedo è: cosa succede quando ho query molto complesse come una query di calcolo delle risorse materiali? In quel tipo di query si lavora con operazioni con set pesanti, il tipo di cosa per cui è stato progettato SQL. Fare quei calcoli all'interno del livello di dominio e lavorare con molti set in esso è come buttare via la tecnologia SQL.

Anche questi calcoli nell'infrastruttura non possono avvenire, poiché il modello DDD consente di modificare l'infrastruttura senza cambiare il livello di dominio e sapere che MongoDB non ha le stesse capacità di SQL Server, ad esempio, che non può accadere.

È una trappola del modello DDD?

In questi giorni, è probabile che le letture (query) vengano gestite in modo diverso rispetto alle scritture (comandi). In un sistema con una query complicata, è improbabile che la query stessa passi attraverso il modello di dominio (che è principalmente responsabile del mantenimento della coerenza delle scritture ).

Hai perfettamente ragione sul fatto che dovremmo rendere a SQL ciò che è SQL. Quindi progetteremo un modello di dati ottimizzato attorno alle letture e una query di quel modello di dati di solito prenderà un percorso di codice che non include il modello di dominio (con la possibile eccezione di una convalida dell'input - assicurando che i parametri nella query sono ragionevoli).

A quanto ho capito, un punto principale è quello di dividere la logica di dominio (Business Logic) dall'infrastruttura (DB, file system, ecc.).

Questo è il fondamento del malinteso: lo scopo di DDD non è quello di separare le cose su una linea dura come "questo è nel server SQL, quindi non deve essere BL", lo scopo di DDD è di separare domini e creare barriere tra quelli che consentono agli interni di un dominio di essere completamente separati dagli interni di un altro dominio e di definire esterni condivisi tra di loro.

Non pensare di "essere in SQL" come la barriera BL / DL, non è quello che è. Invece, pensa a "questa è la fine del dominio interno" come una barriera.

Ogni dominio dovrebbe avere API rivolte verso l'esterno che gli consentano di funzionare con tutti gli altri domini: nel caso del livello di archiviazione dei dati , dovrebbe avere azioni di lettura / scrittura (CRUD) per gli oggetti dati che memorizza. Ciò significa che SQL stesso non è in realtà la barriera, i componenti VIEWe lo PROCEDUREsono. Non dovresti mai leggere direttamente dalla tabella: questo è il dettaglio di implementazione che DDD ci dice che, come consumatore esterno, non dovremmo preoccuparci.

Considera il tuo esempio:

Quello che mi chiedo è: cosa succede quando ho query molto complesse come una query di calcolo delle risorse materiali? In quel tipo di query si lavora con operazioni con set pesanti, il tipo di cosa per cui è stato progettato SQL.

Questo è esattamente ciò che dovrebbe essere in SQL allora, e non è una violazione di DDD. È per questo che abbiamo creato DDD . Con quel calcolo in SQL, questo diventa parte del BL / DL. Che cosa si dovrebbe fare è utilizzare una vista separata / stored procedure / quello che-hanno-te, e mantenere la logica di business separata dal data-layer, come quello è il vostro API esterna. In effetti, il livello dati dovrebbe essere un altro livello dominio DDD, in cui il livello dati ha le proprie astrazioni per funzionare con gli altri livelli dominio.

Anche questi calcoli nell'infrastruttura non possono avvenire, poiché il modello DDD consente di modificare l'infrastruttura senza cambiare il livello di dominio e sapere che MongoDB non ha le stesse capacità di SQL Server, ad esempio, che non può accadere.

Questo è un altro malinteso: afferma che i dettagli di implementazione internamente possono cambiare senza cambiare altri livelli di dominio. Non dice che puoi semplicemente sostituire un intero pezzo di infrastruttura.

Ancora una volta, tieni presente che DDD riguarda nascondere gli interni con API esterne ben definite. Dove siedano quelle API è una domanda completamente diversa, e DDD non lo definisce. Definisce semplicemente che queste API esistono e non dovrebbero mai cambiare .

DDD non è configurato per consentire la sostituzione ad hoc di MSSQL con MongoDB, ovvero due componenti dell'infrastruttura totalmente diversi.

Invece, usiamo un'analogia per ciò che DDD definisce: gas vs auto elettriche. Entrambi i veicoli hanno due metodi completamente diversi per creare la propulsione, ma hanno le stesse API: un on / off, un acceleratore / freno e ruote per spingere il veicolo. DDD afferma che dovremmo essere in grado di sostituire il motore (gas o elettrico) nella nostra auto. Non dice che possiamo sostituire l'auto con una motocicletta, ed è effettivamente ciò che MSSQL → MongoDB è.

Se sei mai stato su un progetto in cui l'organizzazione che paga per ospitare l'applicazione decide che le licenze a livello di database sono troppo costose, apprezzerai la facilità con cui puoi migrare il tuo database / archiviazione dei dati. Tutto considerato, mentre ciò accade, non succede spesso .

Per così dire, puoi ottenere il meglio da entrambi i mondi. Se si considera l'esecuzione di funzioni complesse nel database un'ottimizzazione, è possibile utilizzare un'interfaccia per iniettare un'implementazione alternativa del calcolo. Il problema è che devi mantenere la logica in più posizioni.

Deviando da un modello architettonico

Quando ti trovi in ​​contrasto con l'implementazione di un modello puramente o deviando in qualche area, allora hai una decisione da prendere. Uno schema è semplicemente un modo esemplare di fare le cose per aiutare a organizzare il tuo progetto. A questo punto prenditi del tempo per valutare:

• È questo il modello giusto? (molte volte lo è, ma a volte è solo una brutta misura)
• Devo deviare in questo modo?
• Fino a che punto ho deviato finora?

Scoprirai che alcuni motivi architettonici si adattano all'80-90% della tua applicazione, ma non tanto per i bit rimanenti. La deviazione occasionale dal modello prescritto è utile per motivi prestazionali o logistici.

Tuttavia, se scopri che le tue deviazioni cumulative ammontano a ben oltre il 20% dell'architettura delle tue applicazioni, probabilmente è solo una cattiva scelta.

Se scegli di andare avanti con l'architettura, allora fatevi un favore e documentate dove e perché vi siete allontanati dal modo prescritto di fare le cose. Quando ottieni un nuovo membro entusiasta nel tuo team, puoi indicarlo a quella documentazione che include le misurazioni delle prestazioni e le giustificazioni. Ciò ridurrà la probabilità di richieste ripetute per risolvere il "problema". Tale documentazione aiuterà anche a disincentivare le deviazioni dilaganti.

La logica di manipolazione impostata in cui SQL è bravo può essere integrata con DDD senza problemi.

Diciamo ad esempio che devo conoscere un valore aggregato, il conteggio totale del prodotto per tipo. Facile da eseguire in sql, ma lento se carico tutti i prodotti in memoria e li aggiungo tutti.

Introduco semplicemente un nuovo oggetto Dominio,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

e un metodo sul mio repository

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Certo, forse ora sto facendo affidamento sul mio DB con determinate abilità. Ma tecnicamente ho ancora la separazione e fintanto che la logica è semplice, posso sostenere che non si tratta di "logica aziendale"

Uno dei modi possibili per risolvere questo dilemma è pensare a SQL come a un linguaggio assembly: raramente, se non del tutto, codice direttamente in esso, ma dove le prestazioni contano, devi essere in grado di comprendere il codice prodotto dal tuo C / C ++ / Golang / Rust e magari anche scrivere un piccolo frammento nell'assembly, se non è possibile modificare il codice nella propria lingua di alto livello per produrre il codice macchina desiderato.

Allo stesso modo, nel regno dei database e di SQL, varie librerie SQL (alcune delle quali sono ORM ), ad esempio SQLAlchemy e Django ORM per Python, LINQ per .NET, forniscono astrazioni di livello più elevato ma utilizzano il codice SQL generato ove possibile per ottenere prestazioni. Offrono anche una certa portabilità per quanto riguarda il DB utilizzato, possibilmente con prestazioni diverse, ad esempio su Postgres e MySQL, a causa di alcune operazioni che utilizzano alcuni SQL più specifici per DB specifici.

E proprio come con linguaggi di alto livello, è fondamentale capire come funziona SQL, anche se è solo per riordinare le query fatte con le librerie SQL sopra menzionate, per essere in grado di raggiungere l'efficienza desiderata.

PS Preferirei fare di questo un commento ma non ho una reputazione sufficiente per questo.

Come al solito, questa è una di quelle cose che dipende da una serie di fattori. È vero che c'è molto che puoi fare con SQL. Ci sono anche delle difficoltà nell'usarlo e alcune limitazioni pratiche dei database relazionali.

Come osserva Jared Goguen nei commenti, SQL può essere molto difficile da testare e verificare. I principali fattori che portano a questo sono che non può (in generale) essere scomposto in componenti. In pratica, una query complessa deve essere considerata in toto. Un altro fattore complicante è che il comportamento e la correttezza di SQL dipendono fortemente dalla struttura e dal contenuto dei dati. Ciò significa che testare tutti gli scenari possibili (o persino determinare quali siano) è spesso impossibile o impossibile. Anche il refactoring di SQL e la modifica della struttura del database sono problematici.

L'altro grande fattore che ha portato all'allontanamento da SQL è che i database relazionali tendono a ridimensionarsi solo verticalmente. Ad esempio, quando si creano calcoli complessi in SQL da eseguire in SQL Server, verranno eseguiti sul database. Ciò significa che tutto quel lavoro sta usando le risorse sul database. Più si fa in SQL, più risorse saranno necessarie al database sia in termini di memoria che di CPU. Spesso è meno efficiente eseguire queste operazioni su altri sistemi, ma non esiste un limite pratico al numero di macchine aggiuntive che è possibile aggiungere a tale soluzione. Questo approccio è meno costoso e più tollerante ai guasti rispetto alla creazione di un server database mostro.

Questi problemi possono o meno essere applicabili al problema in questione. Se sei in grado di risolvere il tuo problema con le risorse di database disponibili, forse SQL va bene per il tuo spazio problematico. È necessario considerare la crescita, tuttavia. Potrebbe andare bene oggi, ma tra qualche anno, il costo dell'aggiunta di risorse aggiuntive potrebbe diventare un problema.

È una trappola del modello DDD?

Vorrei prima chiarire alcune idee sbagliate.

DDD non è un modello. E in realtà non prescrive schemi.

La prefazione al libro DDD di Eric Evan afferma:

I principali progettisti di software hanno riconosciuto la modellazione e la progettazione del dominio come argomenti critici per almeno 20 anni, ma sorprendentemente poco è stato scritto su ciò che deve essere fatto o su come farlo. Sebbene non sia mai stata formulata in modo chiaro, una filosofia è emersa come una corrente sotterranea nella comunità degli oggetti, una filosofia che io chiamo design guidato dal dominio.

[...]

Una caratteristica comune ai successi era un ricco modello di dominio che si è evoluto attraverso iterazioni di progettazione ed è diventato parte del tessuto del progetto.

Questo libro fornisce un quadro per prendere decisioni di progettazione e un vocabolario tecnico per discutere la progettazione del dominio. È una sintesi delle migliori pratiche ampiamente accettate insieme alle mie intuizioni ed esperienze.

Quindi, è un modo per avvicinarsi allo sviluppo del software e alla modellazione del dominio, oltre ad alcuni vocaboli tecnici che supportano quelle attività (un vocabolario che include vari concetti e modelli). Inoltre, non è qualcosa di completamente nuovo.

Un'altra cosa da tenere a mente è che un modello di dominio non è l'implementazione OO di esso che può essere trovato nel tuo sistema - è solo un modo per esprimerlo o per esprimerne una parte. Un modello di dominio è il modo in cui pensi al problema che stai cercando di risolvere con il software. È come comprendi e percepisci le cose, come ne parli. È concettuale . Ma non in un certo senso vago. È profondo e raffinato, ed è il risultato del duro lavoro e della raccolta di conoscenze. È ulteriormente perfezionato e probabilmente si è evoluto nel tempo e comporta considerazioni di implementazione (alcune delle quali potrebbero limitare il modello). Dovrebbe essere condiviso da tutti i membri del team (e gli esperti di dominio coinvolti) e dovrebbe guidare il modo in cui implementate il sistema, in modo che il sistema lo rifletta da vicino.

Nulla di tutto ciò è intrinsecamente pro o anti-SQL, anche se gli sviluppatori OO sono forse in genere migliori nell'esprimere il modello nei linguaggi OO e l'espressione di molti concetti di dominio è meglio supportata da OOP. Ma a volte parti del modello devono essere espresse in un diverso paradigma.

Quello che mi chiedo è, cosa succede quando ho domande molto complesse [...]?

Bene, in generale ci sono due scenari qui.

Nel primo caso, alcuni aspetti di un dominio richiedono davvero una query complessa, e forse quell'aspetto è meglio espresso nel paradigma SQL / relazionale, quindi utilizzare lo strumento appropriato per il lavoro. Rifletti quegli aspetti nel tuo pensiero di dominio e il linguaggio usato per comunicare concetti. Se il dominio è complesso, forse questa è una parte di un sottodominio con il proprio contesto limitato.

L'altro scenario è che la necessità percepita di esprimere qualcosa in SQL è il risultato di un pensiero limitato. Se una persona o una squadra sono sempre stati orientati al database nel loro modo di pensare, potrebbe essere difficile per loro, proprio a causa dell'inerzia, vedere un modo diverso di avvicinarsi alle cose. Questo diventa un problema quando il vecchio modo non riesce a soddisfare le nuove esigenze e richiede un po 'di pensiero fuori dagli schemi. DDD, come approccio alla progettazione, riguarda in parte i modi per uscire da quella scatola raccogliendo e distillando le conoscenze sul dominio. Ma tutti sembrano ignorare quella parte del libro e si concentrano su alcuni dei termini e dei modelli tecnici elencati.

Il sequel divenne popolare quando la memoria era costosa, perché il modello di dati relazionali offriva la possibilità di normalizzare i dati e archiviarli efficacemente nel file system.

Ora la memoria è relativamente economica, quindi possiamo saltare la normalizzazione e archiviarla nel formato in cui la usiamo o addirittura duplicare molti degli stessi dati per motivi di velocità.

Considera il database come un semplice IO Device , che ha la responsabilità di archiviare i dati nel file system - sì, lo so che è difficile immaginarlo, perché abbiamo scritto molte applicazioni con importanti logiche aziendali scritte in query SQL - ma prova solo a immaginare che SQL Server è solo un'altra stampante.

Incorporeresti un generatore PDF nel driver della stampante o aggiungeresti un trigger che stamperà la pagina di registro per ogni ordine di vendita stampato dalla nostra stampante?

Presumo che la risposta sarà no, perché non vogliamo che la nostra applicazione sia accoppiata al tipo specifico di dispositivo (nemmeno parlando dell'efficienza di tale idea)

Negli anni '70 -'90 il database SQL era efficiente, ora? - Non è sicuro, in alcuni scenari la query di dati asincrona restituirà i dati richiesti più rapidamente rispetto a più join nella query SQL.

SQL non è stato progettato per query complesse, è stato progettato per archiviare i dati in modo efficiente e quindi fornire interfaccia / linguaggio per eseguire query sui dati memorizzati.

Direi che costruire la tua applicazione attorno al modello di dati relazionali con query complicate è un abuso del motore di database. Ovviamente i fornitori di motori di database sono felici quando abbini strettamente la tua azienda al loro prodotto - saranno più che felici di fornire più funzionalità che lo rendono più forte.