A era da lógica do domínio nos bancos de dados acabou? [fechadas]

Recentemente, deparei com essa opinião de 2016 dizendo que ainda há argumentos para a lógica de domínio no banco de dados.

Eu pensei que isso é totalmente obsoleto. Eu só estou querendo saber se o cara ainda está vivendo nos anos 90 ou isso pode ser realmente verdade. Separe os sistemas legados.

Que tal ter lógica de domínio no banco de dados devido a requisitos de segurança. Isso é realmente uma coisa a se fazer?

Hoje em dia, programadores parecem pensar muito dogmaticamente, especialmente quando lêem os pensamentos que outras pessoas escrevem em seus blogs.

Veja o blog de codificação limpa de Bob Martin, por exemplo. Como observação geral, acho os escritos de Bob Martin bastante claros e lúcidos, de modo que me surpreende o fato de as pessoas estarem constantemente confusas com as coisas que ele escreve, como os princípios do SOLID. Eles ficam preocupados com o que uma "Responsabilidade Única" deveria ser, ou por que algumas classes violam os princípios de Liskov, quando o que provavelmente deveriam estar fazendo é simplesmente se esforçar para escrever um código melhor e obter alguma experiência primeiro, para que o que leem em blogs tem algum contexto.

Basicamente, o que você está dizendo é que o banco de dados deve conter tabelas e dados, e é isso que deve conter. Mas os bancos de dados são exclusivamente adequados para fazer certas coisas que ... bem, os bancos de dados são bons.

O artigo cita estas coisas:

• Integridade e validação de dados (por exemplo, restrições nulas e exclusivas)
• Segurança em nível de linha
• Escrevendo uma API usando procedimentos armazenados
• Cálculo de saldos
• Fazendo as perguntas do banco de dados (ou seja, consultando e relatando)
• Evitando problemas de ORM, como N + 1

como coisas adequadas para colocar no banco de dados. Por acaso concordo com ele.

Motivos para você não colocar lógica de negócios (em geral) em um banco de dados:

• Bloqueio do fornecedor
• Seu banco de dados não é a autoridade central
• Sua equipe não pensa em relação
• Ferramentas inferiores.

Mas essas coisas geralmente se aplicam apenas às técnicas, ferramentas e treinamento para os quais o banco de dados não é adequado de maneira única.

Portanto, como em qualquer outra técnica de desenvolvimento de software, isso depende. Você avalia suas alternativas e toma sua decisão com base no que você acredita ser o melhor curso de ação possível para sua aplicação específica.

A idade do cavalo e do buggy acabou, mas você ainda pode comprar chicotes de buggy.

Por quê? Quando os carros são mais rápidos, mais baratos de manter e negligenciá-los não produzirão visitas da sociedade humana, por que o cavalo e a carroça ainda estão por aí?

Porque às vezes você tem motivos diferentes para fazer algo além dos motivos populares.

O que você deve aprender é por que a lógica do domínio em um banco de dados causa problemas e o que alguém poderia obter com isso. Então decida-se.

Minha visão pessoal:

A lógica do domínio é sobre comportamento. Os bancos de dados são sobre persistência, relacionamentos e, bem, dados. Quando você vê dessa maneira, as regras de negócios não devem estar no banco de dados.

Por outro lado, quem disse que o banco de dados não poderia ter comportamento? Criei bancos de dados de escritório usando o Filemaker. As pessoas chamam de banco de dados, mas também é realmente um ambiente de desenvolvimento de aplicativos inteiro. Tudo perfeitamente integrado em um e chamado de banco de dados.

Wizdom é geralmente encontrado entre visões extremas. Não tenho dúvida de que qualquer um poderia ser feito para funcionar. Ao tentar encontrar o meio, é tentador apenas seguir o rebanho. Vou alertar contra isso aqui.

Um sistema que mantém a lógica do domínio no banco de dados pode funcionar bem. Um sistema que mantém a lógica do domínio fora do banco de dados pode funcionar bem. Um sistema que mistura lógica de domínio nos dois lugares vai me deixar maluco. Não saberei onde colocar um novo comportamento. Não terei certeza de onde encontrar um comportamento antigo.

Se você ainda não pode decidir jogar uma moeda e tomar sua decisão como evangelho para qualquer projeto em particular. Até onde eu sei, essa moeda sabe o que há de melhor, assim como qualquer outra pessoa.

Eu tive um caso em que resolvê-lo na camada de negócios teria sido um verdadeiro matador de desempenho.

Nosso conceito de segurança OO do aplicativo consiste em funções e grupos. E ambos são estruturas recursivas. Escrevemos um procedimento armazenado que resolve a permissão de um usuário em um objeto de domínio.

Há realmente menos necessidades de voltar à lógica do banco de dados. Mas, neste caso, decidi seguir esse caminho. Mas o que você sempre deve considerar: você desiste da abstração. Assim que você tiver lógica de negócios no banco de dados, terá um dia difícil para alterar sua camada de persistência. Portanto, tenha muito, muito cuidado.