O que exatamente consiste em ‘Business Logic’ em uma aplicação?

Question

Já ouvi inúmeras vezes que 'não devemos misturar lógica de negócios com outros códigos' ou declarações como essa.Acho que cada código que escrevo (quero dizer, etapas de processamento) consiste em lógica relacionada aos requisitos de negócios.

Alguém pode me dizer o que exatamente consiste em lógica de negócios?Como ele pode ser diferenciado de outro código?Existe algum teste simples para determinar o que é lógica de negócios e o que não é?

Answer 1

Basta definir o que você está fazendo em inglês simples.Quando você está dizendo coisas de negócios, como “fazer aqueles sofrerem”, “roubar aquele dinheiro”, “destruir esta parte da terra”, você está falando sobre a camada de negócios.Para deixar claro, coisas que te deixam animado vão aqui.

Quando você diz “mostre isso aqui”, “não mostre aquilo”, “deixe mais bonito” você está falando da camada de apresentação.Essas são as coisas que entusiasmam seus designers.

Quando você diz coisas como "salvar isto", "obter isto do banco de dados", "atualizar", "excluir", etc.você está falando sobre a camada de dados.Estas são as coisas que lhe dizem o que manter para sempre a todo custo.

Answer 2

Provavelmente é mais fácil começar dizendo o que não é logíca de negócios.O acesso ao banco de dados ou ao disco não é lógica de negócios.UI não é lógica de negócios.As comunicações de rede não são lógica de negócios.

Para mim, a lógica de negócios são as regras que descrevem como uma empresa opera, não como funciona uma arquitetura de software.A lógica de negócios também tende a mudar.Por exemplo, pode ser um requisito comercial que cada cliente tenha um único cartão de crédito associado à sua conta.Este requisito pode sofrer alterações para que os clientes possam ter vários cartões de crédito.Em teoria, isso deveria ser apenas uma mudança na lógica de negócios e outras partes do seu software não serão afetadas.

Então isso é teoria.No mundo real (como você descobriu), a lógica de negócios tende a se espalhar por todo o software.No exemplo acima, você provavelmente precisará adicionar outra tabela ao seu banco de dados para armazenar os dados extras do cartão de crédito.Você certamente precisará alterar a IU.

Os puristas dizem que a lógica de negócios deve sempre ser completamente separada e, portanto, seria contra a existência de tabelas denominadas "Clientes" ou "Contas" no banco de dados.Levado ao extremo, você acabaria com um sistema incrivelmente genérico e impossível de manter.

Definitivamente, há um forte argumento a favor de manter a maior parte da sua lógica de negócios unida, em vez de espalhá-la por todo o sistema, mas (como acontece com a maioria das teorias) você precisa ser pragmático no mundo real.

Answer 3

Acho que você está confundindo a lógica de negócios com os requisitos do seu aplicativo.Não é a mesma coisa.Quando alguém explica a lógica do seu negócio é algo como:

“Quando um usuário compra um item ele precisa fornecer informações de entrega.A informação é validada com regras x y z.Depois disso ele receberá uma fatura e ganhará pontos, o que dá x% em descontos pelas y ofertas" (desculpem o mau exemplo)

Ao implementar essas regras de negócio você terá que pensar em requisitos secundários, como a forma como a informação é apresentada, como ela será armazenada de forma persistente, a comunicação com os servidores de aplicação, como o usuário receberá a fatura e assim por diante.Todos esses requisitos não fazem parte da lógica de negócio e devem ser dissociados dela.Dessa forma, quando as regras de negócio mudarem você adaptará seu código com menos esforço.Isso é um fato.

Às vezes, a apresentação replica parte da lógica de negócios, principalmente na validação da entrada do usuário.Mas também deve estar presente na camada de lógica de negócios.Em outras situações é necessário mover alguma lógica de negócio para o Banco de Dados, por questões de performance.Isso é discutido por Martin Fowler aqui.

Answer 4

Para simplificar as coisas em uma única linha ...
Lógica de negócios seria um código que não depende/não muda com um detalhe específico de UI/implementação.É uma representação de código das regras, processos, etc.que são definidos/refletem o negócio que está sendo modelado.

Answer 5

Não gosto dos nomes BLL+DAL das camadas, são mais confusos do que esclarecedores.
Chame isso de DataServices e DataPersistence.Isso tornará tudo mais fácil.

Manipulação de serviços, CRUDs de nível de persistência (Criar, Ler, Atualizar, Excluir)

Answer 6

Para mim, " logíca de negócios " compõe todas as entidades que representam os dados aplicáveis ​​ao domínio do problema, bem como a lógica que decide "o que fazer com os dados".

Portanto, deveria realmente consistir em "transporte de dados" (não acesso) e "manipulação de dados".Na verdade, o acesso aos dados (coisas que chegam ao banco de dados) deve estar em uma camada diferente, assim como o código de apresentação.

Answer 7

Se contiver algo sobre coisas como formulário, botão, etc.não é uma lógica de negócios, é uma camada de apresentação.Se contiver persistência para arquivo ou banco de dados, é DAL.Qualquer coisa intermediária é lógica de negócios.Na realidade, qualquer coisa que não seja da UI às vezes é chamada de “lógica de negócios”, mas deve ser algo que diga respeito ao domínio do problema, não à manutenção da casa.

Answer 8

A lógica de negócios é pura abstração, existe independente da materialização/visualização dos dados na frente do seu usuário e independente da persistência dos dados subjacentes.

Por exemplo, no software de preparação de impostos, uma responsabilidade das classes de lógica de negócios seria o cálculo do imposto devido.Eles não seriam responsáveis ​​por exibir relatórios ou salvar e recuperar uma declaração de imposto de renda.

---

@Lars, "serviços" implica uma certa arquitetura.