Trabalho com desenvolvimento web desde 2009, quando comecei com PHP. Quando mudei para o ASP.NET, ouvi muito sobre DDD e OOAD, onde é dado muito foco a essa "lógica de negócios" e "regras de negócios". O ponto é que todos os aplicativos que desenvolvi até agora eram sobre operações CRUD e nunca vi essas coisas na prática.

Simplesmente não consigo imaginar o que essas coisas realmente podem ser na prática. Então, o que realmente é essa lógica de negócios e como isso se encaixa em um aplicativo? Eu sei que eles são implementados como métodos em modelos de domínio, mas quais poderiam ser esses métodos e onde no aplicativo eles poderiam ser usados?

CRUD é um acrônimo que significa Criar, Ler, Atualizar e Excluir. Essas são as quatro operações básicas que você pode executar em uma tupla de banco de dados. Mas sempre há mais aplicativos de negócios do que criar, ler, atualizar e excluir registros do banco de dados.

Vamos começar com algumas definições básicas e, em seguida, examinar alguns exemplos e ver como essas definições são mapeadas para os exemplos e como elas são mapeadas para o software real.

Lógica de negócios ou lógica de domínio é a parte do programa que codifica as regras de negócios do mundo real que determinam como os dados podem ser criados, armazenados e alterados. Ele prescreve como os objetos de negócios interagem entre si e aplica as rotas e os métodos pelos quais os objetos de negócios são acessados ​​e atualizados.

As Regras de Negócios descrevem as operações, definições e restrições que se aplicam a uma organização. As operações formam coletivamente um processo; toda empresa usa esses processos para formar sistemas que realizam tarefas.

Agora, vamos trabalhar com alguns exemplos.

Transferindo dinheiro de uma conta corrente para outra

Primeiro, quais são as coisas que você precisa saber (entrada)?

• A identidade da pessoa que faz a transferência
• A quantia em dinheiro a ser transferida
• O número da conta corrente da fonte
• O número da conta corrente de destino

Quais são algumas das "regras de negócios" que devem ser aplicadas?

• A pessoa que faz a solicitação deve ter autoridade para fazê-lo.
• A transação deve ser atômica .
• A transação pode ter requisitos de relatório ao governo, se exceder um determinado valor

Por "atômica", quero dizer que a transação deve ser completamente bem-sucedida ou falhar completamente. Você não pode ter transações de contas nas quais o dinheiro é retirado de uma conta sem chegar na outra (o dinheiro desaparece) ou o dinheiro é depositado em uma conta, mas não debitado de outra conta (o dinheiro aparece magicamente do nada).

Encomendar algo da Amazon.

O que você precisa saber?

• A identidade da pessoa que está solicitando
• Informação de envio
• Informações de pagamento
• Método de pagamento
• Quantidade e quantidade de cada item a ser enviado
• Como enviar (durante a noite, barco lento ou super saver)
• Taxa de imposto estadual

O que acontece depois que o pedido é feito?

• Os itens são retirados do estoque
• Quantidades disponíveis são debitadas
• Os itens são embalados para remessa
• Itens fora de estoque com pedidos pendentes
• Itens que caem abaixo das quantidades mínimas são pedidos
• Uma remessa ou duas?

• Uma fatura / lista de remessa é impressa e colocada com o pedido

  ..etc.

CRUD é simplesmente o Criar, Ler, Atualizar, Excluir que um aplicativo faz.

Até certo ponto, um rastreador de erros também é um aplicativo CRUD. Crie bugs, leia (exiba) os bugs, atualize os bugs e, talvez, exclua-os.

No entanto, há mais em um rastreador de erros do que apenas CRUD.

• Um desenvolvedor não tem permissão para marcar o bug verificado ou fechado - isso faz parte do trabalho do controle de qualidade. Portanto, existe algum código para garantir que alguém que não tenha a função de controle de qualidade não possa marcar um bug como fechado ou verificado.
• Ninguém, exceto um gerente de projeto, pode realmente excluir um bug.
• Para que um bug seja marcado como "teste-me", deve haver pelo menos um commit de código contra o bug.
• Somente um bug que esteja no estado 'fechado' pode ser movido para o estado 'reabrir'
• O desenvolvedor atribuído ao bug não pode movê-lo de 'revisão de código' para 'revisão de código concluída'
• O controle de qualidade e os desenvolvedores podem ver apenas os bugs nos projetos aos quais estão atribuídos.

O código que implementa o acima é a lógica de negócios do aplicativo.

A restrição de fluxos de trabalho ou quem pode executar as várias operações no CRUD. É isso que separa um aplicativo CRUD de outro. São as partes em que você precisa fazer com que os negócios digam como o aplicativo funciona. Quão lógico é ... bem, isso é melhor discutido com uma cerveja fora do alcance da voz do gerente de projeto. Mas isso é o que é a lógica de negócios.

Claro, é possível escrever um aplicativo CRUD 'puro' onde não há funções, tudo pode ser modificado e visualizado - mas essas são a exceção e não a regra.

A lógica de negócios é a lógica que você está gravando em seu programa para lidar com as regras de negócios que você recebe.

Quando você começa a entrar em regras de negócios, isso tende a estar em um nível superior ao próprio crud ou à lógica de negócios. Isso costuma ser o que você recebe de um analista de negócios que trabalha com o negócio.

Considere neste exemplo, um programa que determina como lidar com a devolução de um item em uma mesa de devolução em uma loja.

• Se o recibo for igual ou superior a 90 dias, somente o crédito na loja poderá ser concedido
• Se o recibo tiver menos de 90 dias, credite a proposta com a qual o recibo foi usado para compra (o crédito volta no cartão de crédito, o dinheiro volta ao dinheiro, o crédito da loja vai ao crédito da loja) ... a menos que era um cheque; nesse caso, use dinheiro.

Essas são algumas regras de negócios. Eles não falam com a parte CRUD do aplicativo.

Ao trabalhar com regras de negócios, você pode encontrá-las com freqüência em um mecanismo de regras (por exemplo, Windows Workflow Foundation Rules Engine ) em vez de escrever o código bruto no seu sistema.

Perceba que a distinção lógica / regras é uma terminologia e pode ser discutida a noite toda (melhor tomar uma cerveja novamente). Embora essa não seja uma distinção incomum, os dois podem se misturar.

Outras respostas estão corretas. Um pensamento adicional ...

A lógica de negócios é portátil

Se você fosse reimplementar um projeto de software em uma linguagem de programação diferente, digamos, passando de Turbo Pascal para Java , lógica de negócios e regras de negócios é o que os projetos antigos e novos teriam em comum .

A linguagem de programação seria diferente. O código fonte seria totalmente diferente. As ferramentas ( IDE , compiladores e outras) podem ser totalmente diferentes. A interface do usuário pode ser totalmente reorganizada ou ter uma aparência diferente . A documentação provavelmente seria diferente. Mas o objetivo dos dois projetos, os resultados finais do trabalho realizado / os objetivos alcançados, seriam os mesmos.

A lógica de negócios consiste basicamente em 2 grandes categorias: validação e fluxo. A lógica comercial diz que a quantidade 1 deve ser maior ou igual à quantidade 2 - por exemplo, o número de itens a serem comprados deve ser menor ou igual ao número de itens em estoque.

Em um aplicativo, o pessoal da empresa diz que essa é uma regra comercial e, portanto, você escreve um código para reforçar essa lógica comercial (validação). Outra aplicação dirá que, se o número de itens pedidos for maior que o número de itens em estoque, aceite o pedido e faça seu próprio pedido pela diferença mais 20%, e assim você escreverá essa lógica de negócios (fluxo) .

O CRUD é simplesmente colocar e retirar dados de armazenamento e alterá-los. A lógica de negócios determina o que você faz com esses dados e que transformações você pode fazer com eles. O seu cliente nasceu no futuro, com menos de 5 anos, de uma determinada área geográfica (descontos para moradores / visitantes). O CRUD é simples, sabendo que você pode obter um crédito fiscal para crianças apenas se a criança viveu com você por mais da metade do tempo em que esteve vivo no ano civil, NÃO por apenas mais de 6 meses, é mais complexo.

Regras ou lógica de negócios são tudo que não pertencem à mecânica da interface do usuário (o "material de programação"). São as coisas que você ainda teria que aplicar se estivesse fazendo essa transação ou o que quer que seja há 100 anos (manualmente). Por exemplo, quando aplicar imposto sobre vendas a uma compra.

A "lógica de negócios" de um programa ou aplicativo é a parte do código que realmente faz as coisas com a entrada (do usuário, do sistema operacional e etc.). As "regras de negócios" de um aplicativo geralmente são os parâmetros definidos pelo próprio programa (como lidar com as entradas). Pelo menos, é assim que ouvi falar de muitas pessoas. São termos bastante semelhantes para descrever partes do código.