L'età della logica di dominio nei database è finita? [chiuso]

Recentemente mi sono imbattuto in questa opinione del 2016 dicendo che c'è ancora motivo per la logica di dominio nel database.

Ho pensato che questo è totalmente obsoleto. Mi chiedo solo se il ragazzo vive ancora negli anni '90 o questo può essere davvero vero. Mettere da parte i sistemi legacy.

Che dire di avere la logica di dominio nel database a causa dei requisiti di sicurezza. È davvero una cosa da fare?

Oggigiorno i programmatori sembrano pensare in modo molto dogmatico, specialmente quando leggono i pensieri che altre persone scrivono nei loro blog.

Prendiamo ad esempio il blog Clean Coding di Bob Martin. Come osservazione generale, trovo gli scritti di Bob Martin abbastanza chiari e lucidi, quindi mi sconcerta il fatto che le persone siano costantemente confuse dalle cose che scrive, come i principi SOLID. Si bloccano su ciò che dovrebbe essere una "responsabilità singola", o perché una classe viola i principi di Liskov, quando quello che probabilmente dovrebbero fare è semplicemente quello di sforzarsi di scrivere un codice migliore e ottenere prima qualche esperienza, in modo che ciò che leggono i blog hanno un certo contesto.

Fondamentalmente quello che stai dicendo è che il database dovrebbe contenere tabelle e dati, e questo è tutto ciò che dovrebbe contenere. Ma i database sono adatti in modo univoco a fare determinate cose in cui ... beh, i database sono bravi a farlo.

L'articolo cita queste cose:

• Integrità e convalida dei dati (ad es. Vincoli nulli e univoci)
• Sicurezza a livello di riga
• Scrivere un'API usando le stored procedure
• Calcolo dei saldi
• Porre le domande sul database (es. Query e rapporti)
• Evitare problemi ORM come N + 1

come cose adatte da inserire nel database. Mi capita di essere d'accordo con lui.

Motivi per cui non si inserisce la logica aziendale (in generale) in un database:

• Blocco del fornitore
• Il tuo database non è l'autorità centrale
• La tua squadra non pensa in modo relazionale
• Attrezzatura inferiore.

Ma queste cose generalmente si applicano solo a quelle tecniche, strumenti e formazione per i quali il database non è adatto in modo univoco.

Quindi, come con qualsiasi altra tecnica di sviluppo del software, dipende. Valuta le tue alternative e prendi la tua decisione in base a ciò che ritieni sia il miglior modo di agire possibile per la tua specifica applicazione.

L'età di cavallo e buggy è finita, ma puoi ancora comprare fruste buggy.

Perché? Quando le macchine sono più veloci, più economiche da mantenere e trascurarle non produrrà visite dalla società umana, perché il cavallo e il carro sono ancora in giro?

Perché a volte hai motivi diversi per fare qualcosa oltre ai motivi popolari.

Quello che dovresti imparare è perché la logica di dominio in un database causa problemi e ciò che chiunque potrebbe uscirne. Quindi prendi una decisione.

La mia visione personale:

La logica del dominio riguarda il comportamento. I database riguardano persistenza, relazioni e, beh, dati. Quando lo vedi in questo modo le regole di business non dovrebbero essere nel database.

D'altra parte chi, ha detto che il database non potrebbe avere un comportamento? Ho creato database per ufficio usando Filemaker. Le persone lo chiamano database ma in realtà è anche un intero ambiente di sviluppo di applicazioni. Tutto perfettamente integrato in uno e chiamato un database.

Wizdom si trova di solito tra visioni estreme. Non ho dubbi che neanche si potrebbe far funzionare. Quando si tenta di trovare il centro, si è tentati di seguire solo la mandria. Lo ammonirò qui.

Un sistema che mantiene la logica di dominio nel database può funzionare bene. Un sistema che mantiene la logica di dominio fuori dal database può funzionare bene. Un sistema che mescola la logica del dominio in entrambi i posti mi farà impazzire. Non saprò dove mettere nuovi comportamenti. Non sarò sicuro di dove trovare il vecchio comportamento.

Se ancora non riesci a decidere di lanciare una moneta e prendere la sua decisione come vangelo per un particolare progetto. Per quanto ne so, quella moneta sa cosa è meglio come chiunque altro.

Ho avuto un caso in cui risolverlo a livello aziendale sarebbe stato un vero killer delle prestazioni.

Il nostro concetto di sicurezza OO dell'applicazione è costituito da ruoli e gruppi. Ed entrambi sono strutture ricorsive. Abbiamo scritto una procedura memorizzata che risolve l'autorizzazione per un utente su un oggetto dominio.

Ci sono davvero meno necessità di ricorrere alla logica del database. Ma in questo caso ho deciso di andare in quel modo. Ma quello che devi sempre considerare: rinunci all'astrazione. Non appena hai una logica aziendale nel database, hai una dura giornata per cambiare il tuo livello di persistenza. Quindi stai molto attento.