¿Ha terminado la era de la lógica de dominio en las bases de datos? [cerrado]

Recientemente me topé con esta opinión de 2016 diciendo que todavía hay motivos para la lógica de dominio en la base de datos.

Pensé que esto es totalmente obsoleto. Me pregunto si el tipo todavía vive en los 90 o si esto puede ser realmente cierto. Ponga a un lado los sistemas heredados.

¿Qué pasa con tener lógica de dominio en la base de datos debido a los requisitos de seguridad? ¿Es eso realmente algo que hacer?

database

— ps-aux
fuente

¿De verdad leíste ese artículo completo? Creo que el autor aclara muy bien su punto de vista y explica qué partes del BL cree que están mejor ubicadas en una base de datos y cuáles no. Entonces, ¿con qué puntos de ese artículo estás luchando exactamente ?

— Doc Brown

Sí, cerró el 18 de febrero de 2009 y ahora es falso.

— Michael Durrant

Es curioso Leí a este tipo, dando muchos ejemplos de SQL (fuertemente vinculados a Oracle) y luego no puedo evitar recordar a mi cliente diciéndome: olvidé comprar la licencia de Oracle para el PRE PRE. Lo tenemos para PRO pero no para PRE. Tendrás que implementar la aplicación, contra MySQL en PRE y Oracle en PRO, por un tiempo ... Le preguntaré a ese tipo dónde van todas las características brillantes de Oracle ... (El problema aquí fue que por alguna razón No quiero saberlo, el arquitecto decidió utilizar el mapeo nativo de filas SQL en lugar de Orm, pero aún así está cerca del problema de estar bloqueado al proveedor de DB) .

— Laiv

@Laiv: Eso es una locura, y ninguna cantidad de ORM u otras abstracciones te salvarán. Básicamente, está implementando código no probado en producción con dicha configuración.

— JacquesB

"¿Se acabó la era de la lógica de dominio en las bases de datos?" Dios, eso espero.

— lunchmeat317

Respuestas:

Los programadores de hoy en día parecen pensar muy dogmáticamente, especialmente cuando leen los pensamientos que otras personas escriben en sus blogs.

Tome el blog de codificación limpia de Bob Martin, por ejemplo. Como observación general, los escritos de Bob Martin me parecen bastante claros y lúcidos, por lo que me desconcierta que la gente se confunda constantemente con las cosas que escribe, como los principios SOLID. Se obsesionan con lo que debería ser una "responsabilidad única", o por qué alguna clase viola los principios de Liskov, cuando lo que probablemente deberían estar haciendo es simplemente esforzarse por escribir un mejor código, y obtener algo de experiencia primero, para que lo que lean Los blogs tienen algún contexto.

Básicamente, lo que está diciendo es que la base de datos debe contener tablas y datos, y eso es todo lo que debe contener. Pero las bases de datos son especialmente adecuadas para hacer ciertas cosas que ... bueno, las bases de datos son buenas.

El artículo cita estas cosas:

Integridad y validación de datos (por ejemplo, restricciones nulas y únicas)
Seguridad a nivel de fila
Escribir una API usando procedimientos almacenados
Calcular saldos
Hacer preguntas a la base de datos (es decir, consultar e informar)
Evitar problemas de ORM como N + 1

como cosas adecuadas para poner en la base de datos. Estoy de acuerdo con él.

Motivos por los que no coloca la lógica empresarial (en general) en una base de datos:

Dependencia de un proveedor
Su base de datos no es la autoridad central.
Tu equipo no piensa relacionalmente
Utillaje inferior.

Pero estas cosas generalmente solo se aplican a aquellas técnicas, herramientas y capacitación para las cuales la base de datos no es especialmente adecuada.

Entonces, como con cualquier otra técnica en el desarrollo de software, depende. Evalúa sus alternativas y toma su decisión en función de lo que cree que es el mejor curso de acción posible para su aplicación específica.

— Robert Harvey
fuente

Un muy buen desglose y una mejor manera de enmarcar la pregunta.

— candied_orange

La edad del caballo y el cochecito ha terminado, pero aún puede comprar látigos con errores.

¿Por qué? Cuando los autos son más rápidos, más baratos de mantener y descuidarlos no generará visitas de la sociedad humanitaria, ¿por qué el caballo y el carro siguen ahí?

Porque a veces tienes diferentes razones para hacer algo además de las razones populares.

Lo que debería estar aprendiendo es por qué la lógica de dominio en una base de datos causa problemas y lo que cualquiera podría obtener de ella. Entonces toma tu propia decisión.

Mi punto de vista personal:

La lógica de dominio se trata de comportamiento. Las bases de datos son sobre persistencia, relaciones y, bueno, datos. Cuando lo vea de esta manera, las reglas de negocio no deberían estar en la base de datos.

Por otro lado, ¿quién dijo que la base de datos no podía tener comportamiento? He creado bases de datos de oficina usando Filemaker. La gente lo llama una base de datos, pero también es realmente un entorno de desarrollo de aplicaciones completo. Todo perfectamente integrado en uno y llamado base de datos.

Wizdom generalmente se encuentra entre puntos de vista extremos. No tengo dudas de que ninguno podría ser hecho para trabajar. Al tratar de encontrar el medio, es tentador seguir al rebaño. Voy a advertir contra esto aquí.

Un sistema que mantiene la lógica de dominio en la base de datos puede funcionar bien. Un sistema que mantiene la lógica de dominio fuera de la base de datos puede funcionar bien. Un sistema que mezcla la lógica de dominio en ambos lugares me va a volver loco. No sabré dónde poner un nuevo comportamiento. No estaré seguro de dónde encontrar el viejo comportamiento.

Si aún no puede decidir lanzar una moneda y tomar su decisión como evangelio para cualquier proyecto en particular. Por lo que puedo decir, esa moneda sabe lo que es mejor que cualquier otra persona.

— naranja confitada
fuente

Su respuesta parece que ni siquiera echó un vistazo al artículo vinculado por el OP (no es que yo diga que el autor tiene razón o no), pero ¿puede decirnos dónde está de acuerdo o difiere de las opiniones descritas en ese artículo?

— Doc Brown

@DocBrown Yo tampoco lo leí, pero esta respuesta es buena de todos modos, donde estaría totalmente de acuerdo. Y aborda la pregunta del OP (última oración), no un artículo citado.

— qwerty_so

@DocBrown No creo que el artículo lea el artículo del Tío Bob que cita : "Las arquitecturas de complementos son muy robustas porque se pueden evitar reglas comerciales estables de alto valor dependiendo de módulos volátiles de bajo valor, como interfaces de usuario y bases de datos". El tío Bob tiene opiniones más fuertes contra esta idea que yo. Este artículo Cherry recoge del artículo de Bob y hace que parezca que Bob está diciendo algo que no está diciendo.

— candied_orange

Tuve un caso en el que resolverlo en la capa empresarial habría sido un verdadero asesino del rendimiento.

Nuestro concepto de seguridad OO de aplicación consta de roles Y grupos. Y ambas son estructuras recursivas. Escribimos un procedimiento almacenado que resuelve el permiso para un usuario en un objeto de dominio.

Realmente hay menos necesidad de recurrir a la lógica de la base de datos. Pero en este caso decidí ir por ese camino. Pero lo que siempre debes tener en cuenta: renuncias a la abstracción. Tan pronto como tenga lógica empresarial en la base de datos, tendrá un día difícil para cambiar su capa de persistencia. Así que ten mucho cuidado.

— oopexpert
fuente