I modelli di dominio nel database possono essere una soluzione sostenibile?

Ho appena iniziato un nuovo lavoro come sviluppatore di database per un'azienda di dimensioni medio-piccole, basata sulla tecnologia Microsoft. Ho notato presto quante pratiche si discostano da ciò che mi è stato insegnato a scuola per quanto riguarda le migliori pratiche, i modelli di progettazione, i test e la gestione dei progetti.

Ciò che mi infastidisce di più è il modo in cui il nostro principale sviluppatore di database (d'ora in poi chiamato "John") mantiene lo schema del modello nel database! Lo facciamo avendo 3 tavoli "magici"; uno per gli schemi di database, uno per le tabelle e uno per le colonne.

L'inserimento di un record nella tabella " Tabelle " genera (tramite un trigger di database) la tabella corrispondente effettiva. Inserendo una riga nella tabella " Righe " si aggiorna la tabella referenziata con quella riga. Questi vengono a loro volta letti dal suo programma C # fatto in casa per generare modelli C #, che vengono utilizzati dagli sviluppatori frontend per i controller e verso l'esterno.

A parte questo, la maggior parte dello sviluppo avviene secondo il framework MVC ASP.NET .

Vedo un paio di difetti con questo approccio:

• Abbiamo bisogno che mantenga l'ORM, e raramente ha il tempo di farlo (la sicurezza del lavoro è buona!)
• I trigger per le tabelle "Tabelle" e "Righe" sono imperfetti. Non supportano gli aggiornamenti delle tabelle, né i vincoli Check o le funzionalità più "avanzate". Sebbene potremmo sicuramente migliorarli, non sono ancora sicuro che questa sia la strada da percorrere.
• Mantenere la logica programmatica nel database sembra strano e restrittivo (anche se è possibile estendere i suoi modelli tramite C #).
• Il suo generatore di modelli C # deve essere gestito manualmente da una delle 3 persone (tra le quali io sono uno) e non è ancora abbastanza maturo per essere incluso in un processo di compilazione automatizzato.

Diverse persone hanno suggerito di introdurre gradualmente un prodotto vero e testato come Entity Framework , ma lui lo rifiuta, affermando che mantenere la logica di business nel livello di codice è adatto solo per applicazioni su piccola scala e progetti bootstrap per le startup.

Questo post sta conducendo verso qualcosa che potrebbe sembrare una discussione supponente, ma questa non è la mia intenzione. Voglio solo qualche chiarimento riguardo al nostro approccio architettonico.

Mantenere i modelli di dominio nel database può essere una soluzione sostenibile per un'azienda in crescita?

Stai descrivendo una piattaforma interna.

Il problema con le piattaforme interne è che reinventate tutti i meccanismi di una piattaforma o tecnologia (in questo caso, un database relazionale) che sono stati affinati e perfezionati nel corso di decenni di evoluzione e impegno, ma reinventandolo male. Stai aggirando tutte le ottimizzazioni disponibili per coloro che scelgono un design più convenzionale e scambiando semplicità ed eleganza iniziali per complessità e difficoltà future.

Detto questo, se il prodotto finale di questo processo sono tabelle reali e classi reali che modellano oggetti di domini aziendali reali , non vedo molto danno in questo approccio, a parte l'immaturità degli strumenti. Stack Exchange utilizza in realtà il proprio ORM nostrano e questo sembra aver funzionato per loro. Quindi so che questo tipo di approccio "cottage" può funzionare.

Si noti che la maggior parte degli ORM che adottano l'approccio "table-first" semplicemente guarda la struttura della tabella nel database per creare le classi. Le tabelle "table" e "row" create dal tuo amico sono semplicemente metadati già presenti nelle tabelle di sistema della maggior parte dei moderni sistemi di database relazionali.

Ulteriori letture
Il progetto "Vision", un ammonimento sull'effetto della piattaforma interna
_{(puoi saltare il preambolo e iniziare a leggere dal sottotitolo "Presentazione di Vision")}