Qual é a diferença entre lógica de negócios e aplicativos? [fechadas]

Observe que eu fiz a mesma pergunta no stackoverflow, mas eles me orientaram a perguntar aqui.

Enquanto estou tentando discernir a diferença entre a lógica do aplicativo e a lógica comercial, encontrei um conjunto de artigos, mas infelizmente há uma contradição entre eles.

Aqui eles dizem que são os mesmos, mas a resposta aqui é totalmente diferente.

Para mim, eu entendo da seguinte maneira:

Se procurarmos a definição da Logicpalavra no Google, obteremos

sistema ou conjunto de princípios subjacentes aos arranjos de elementos em um computador ou dispositivo eletrônico, a fim de executar uma tarefa especificada.

Portanto, se a lógica for set of principles underlying the arrangements of elements, a lógica de negócios deve ser set of principles underlying the arrangements of the business rules, em outras palavras, significa que as regras que devem ser seguidas para obter um sistema refletem suas necessidades de negócios.

E, para mim, a lógica do aplicativo é the principles that the application based on, em outras palavras, como aplicar essas regras para obter um sistema que reflita suas necessidades comerciais, por exemplo, devo usar o MVC ou não devo ?, devo usar SQL ou MSSQl ?.

Então, por favor, alguém poderia me ajudar a me livrar da confusão sobre a diferença entre o aplicativo e a lógica de negócios.

Concordo com o LoztInSpace da SO que essa é uma resposta bastante opinativa e que todos podem ter definições ligeiramente diferentes. Especialmente se influências históricas estiverem envolvidas. É assim que eu definiria os termos:

Lógica de negócios é lógica, criada com colaboração e acordo com especialistas em negócios. Se o especialista em negócios disser que "O cliente não pode sacar mais dinheiro do que ele tem em sua conta.", Essa é uma regra de negócios. No mundo ideal, essa lógica estaria em algum tipo de biblioteca ou serviço, para que possa ser reutilizada em vários aplicativos ou alterada em todos os aplicativos relevantes ao mesmo tempo.

A lógica da aplicação é simplesmente tudo o resto. O exemplo pode ser "clicar neste botão abre a janela para adicionar novo cliente". Não tem nada a ver com negócios, mas ainda é a lógica que precisa ser implementada. No mundo ideal, a lógica do aplicativo usará a biblioteca ou o serviço, que está implementando as regras de negócios. Vários aplicativos, cada um com uma lógica de aplicativo diferente, podem reutilizar uma lógica de negócios. Imagine aplicativo da web, serviço da web e aplicativo móvel, todos operando usando uma lógica de negócios, mas cada um claramente precisa de lógicas de aplicativo diferentes.

A razão pela qual acho que os dois se confundem é que mantê-los separados é extremamente difícil. Mesmo que você faça o máximo para mantê-los separados, os casos de uso surgem onde é necessário misturá-los. Se, por exemplo, você tiver toda a lógica de negócios em serviço, ela será mantida separada. Mas ter alguma lógica de negócios no aplicativo local que esteja usando o serviço pode aumentar a capacidade de resposta ou o conforto do usuário, porque o aplicativo local não precisa chamar o serviço para cada pequena alteração.

Outra razão pela qual eles são misturados é o de muitas pessoas não técnicas. A interface do usuário é "o aplicativo", portanto, qualquer coisa refletida na interface do usuário é importante. No caso ideal de "lógica de negócios", não há interface do usuário. Provavelmente haveria um conjunto de testes automatizados para verificar a lógica, mas nada que possa ser mostrado às pessoas de negócios. Então, para as pessoas de negócios, tudo é o mesmo tipo de "lógica". IMO.

Como outros já apontaram, esses termos não têm um significado universalmente aceito. Descreverei as definições que encontrei com mais frequência, ou seja, em vários projetos com empresas diferentes.

A lógica de negócios define um modelo de propósito geral normalizado do domínio de negócios para o qual um aplicativo é gravado, por exemplo

• Classes como Customer, Order, OrderLine, e associações como customer-order, e assim por diante.
• Operações de uso geral, como registerCustomer,cancelOrder

Muitas vezes, esse modelo de classe é mapeado para um modelo de banco de dados e o mapeamento é implementado usando o ORM. As operações são normalmente executadas cada uma em sua própria transação e fornecem a API básica para modificar o banco de dados, ou seja, o estado persistente do aplicativo.

A lógica do aplicativo é uma camada construída sobre a lógica de negócios e serve para implementar casos de uso específicos. Os módulos lógicos de aplicativos podem usar representação ad-hoc de dados, por exemplo, uma classe CustomerSummary sem nenhuma associação, Orderse você deseja listar apenas clientes. Essa representação ad-hoc de dados deve ser mapeada para a representação normalizada subjacente fornecida pelo modelo de negócios. Por exemplo, CustomerSummarypode ser definido como uma visualização em cima de Customer.

Observe que o limite entre as duas camadas pode não estar tão claramente definido. Por exemplo, após a implementação de vários casos de uso, é possível notar estruturas de dados semelhantes na lógica do aplicativo e decidir unificá-las (normalizá-las) e movê-las para a lógica de negócios.

Todo sistema ou aplicativo terá suas próprias definições do que é lógica de negócios e o que é lógica de aplicativo. Será explícito ou implícito.

Na minha experiência, aplicativos orientados a dados (por exemplo, bancos de dados etc.) tendem a ter uma definição mais formal do que é a lógica de negócios.

A lógica do aplicativo tende a focar na obtenção de informações do ponto A ao ponto B, a lógica de negócios gira em torno do que são as informações - e o idioma da lógica de negócios geralmente é específico do domínio. Em outras palavras, a lógica do aplicativo está focada na pergunta "como funciona?", A lógica de negócios em "o que faz?" - novamente, a distinção pode ser muito nebulosa e é mais frequente que não específica do domínio.

Na verdade, são termos diferentes para a mesma coisa - a "camada intermediária" do código do programa que faz as coisas que você deseja que seu programa execute. Como muitas coisas no software, não há terminologia rígida para partes de um sistema, pois não há definições formais únicas para a construção de sistemas.

Então, às vezes, as pessoas chamam isso de lógica de negócios, outras são de lógica de aplicativo, outras, de lógica de programa. Não se preocupe em tentar definir isso de forma tão rígida, quase todos os sistemas variam na forma como são construídos; então, fique contente por haver apenas esse nível menor de imprecisão na terminologia!