Ho lavorato in un'app che gestisce relazioni e vincoli a livello di applicazione.
In che modo ciò influisce sul cambiamento dei database mantenendo il software applicativo? Ciò significherebbe che il database sarebbe semplicemente "Persistenza dei dati come servizio". In che modo ciò influisce sul disaccoppiamento, la modularità e l'ortogonalità?
In generale, i modelli di dominio richiedono sia vincoli che transazioni per mantenerli sani mentre vengono aggiornati. (Certo alcuni modelli di dominio sono troppo semplici per richiederli, ma molti non lo sono.) Questi vincoli possono essere applicati per codice ovunque, di solito nel o dal database, un servizio o un'applicazione. Quello che non vogliamo è la persistenza grezza esposta senza i vincoli e le transazioni appropriati del modello di dominio.
Quindi, se i vincoli e le transazioni sono applicati all'interno del database, il database può essere condiviso su più servizi e applicazioni.
Tuttavia, se i vincoli sono applicati in un servizio, il servizio può essere condiviso da altri servizi e dalle applicazioni, ma sarebbe imprudente condividere il database direttamente.
Si potrebbe creare un caso per la condivisione del database in un modo di sola lettura, ma poiché una parte della logica del modello di dominio viene gestita dal servizio, questo può essere soggetto a errori. Ad esempio, diciamo che il database è un semplice meccanismo di persistenza e non offre vincoli o transazioni. Possiamo avere un servizio che avvolge questo database; il servizio è destinato alla condivisione e il servizio offre vincoli e transazioni.
Se il servizio di wrapping del database è bypassato - anche a scopo di sola lettura - il lettore può vedere uno stato incoerente, vale a dire se una singola transazione richiede più scritture, il lettore può vedere una di quelle scritture senza vederle tutte . Il modello dovrebbe essere visibile solo tra transazioni intere, non all'interno di una transazione in corso, in quanto ciò potrebbe esporre lo stato di modello falso.
Come potete immaginare, se i vincoli del modello di dominio sono applicati dall'applicazione, allora l'applicazione può essere condivisa (cioè può esporre servizi) ma probabilmente il database non dovrebbe. Dovrebbero essere necessarie due applicazioni diverse che accedono allo stesso database per applicare la stessa logica di vincolo, che rende il codice wet (vs. DRY). Ancora più problematiche sono le transazioni quando due diverse applicazioni accedono allo stesso storage sottostante e non protetto; le due applicazioni dovranno coordinarsi tra loro, magari utilizzando le funzionalità di blocco dei file del sistema operativo. Anche in questo caso, esiste un codice wet vs DRY se entrambe le applicazioni hanno il coordinamento appropriato. Uno di questi può essere risolto inserendo il codice in una libreria da utilizzare da entrambe le applicazioni, ma rimane il problema delle correzioni di bug e dei potenziali requisiti per il roll out coordinato.
In generale, la soluzione migliore è quella di avvolgere la persistenza non protetta all'interno di un singolo servizio, che è quindi il punto che supporta la condivisione. Un database SQL praticamente è quel servizio, supponendo che usi in modo appropriato i suoi vincoli e le sue transazioni; SQL non espone la persistenza sottostante non protetta.
Leggi altre domande sui tag design database architecture database-design architectural-patterns