Devo colocar a lógica de cálculo em uma entidade ou na camada de negócios?

Recentemente, me deparei com uma pergunta sobre se um cálculo simples deveria ser colocado na camada Entidade ou se a Entidade era pura apenas para armazenar os dados brutos e deixar as lógicas de cálculo na camada de negócios.

Portanto, minha pergunta é se é sensato encapsular cálculos simples nas propriedades em uma classe de entidade?

design-patterns

— Kata
fonte

Depende do tipo de arquitetura que você deseja.

No Design Orientado a Domínio, você criaria um Modelo de Domínio que teria dados e funcionalidade.

Isso significaria que um Orderpossui uma propriedade (ou método) que retornaria o preço total do pedido com base no OrderLines. Eles Ordertambém teriam um método AddOrderItem(Product product, int amount)e Orderverificariam se já existe um OrderLinepara esse produto específico.

Nesse modelo, você também teria objetos que não são entidades reais, como um Repositorypara acessar dados ou um Factorypara criar entidades. Estes são chamados de Serviços de Domínio. Uma camada de aplicativo é responsável por chamar os Serviços de Domínio (por exemplo, para recuperar uma entidade do banco de dados) e, em seguida, executará a funcionalidade na entidade. O Application Layerdeve ser o mais fino possível.

Este é um bom artigo sobre DDD, que explica esses conceitos em mais detalhes.

Você também pode usar um modelo de domínio anêmico . Isso significa que suas entidades consistem em propriedades get / set e não contêm comportamento. Nesse design, sua Camada de Negócios conterá o comportamento, como calcular o Orderpreço e verificar se há duplicatas OrderLines.

Existem opiniões diferentes sobre se um Modelo de Domínio Anêmico é uma coisa ruim. Pessoalmente , prefiro um modelo de domínio real.

Este artigo descreve as diferenças entre um modelo de domínio anêmico e não anêmico.

— Wouter de Kort
fonte

Olá Wouter, obrigado pela resposta e pelos links. Parece-me que tenho uma opinião errada de que, quando usado o modelo de domínio Anêmico, todas as lógicas de negócios (mesmo as mais simples) devem ser colocadas na camada de negócios. Isso parece absurdo em alguns casos em que as lógicas de negócios são realmente apenas dependendo do modelo em si. Por exemplo, uma propriedade é calculada a partir das propriedades existentes no modelo. Não consegui encontrar uma razão sensata para colocar as lógicas de negócios que dependem do próprio modelo na camada de negócios.

Em um modelo de domínio anêmico, como temos classes de negócios e classes de entidade, como nomear classes corretamente para evitar confusão entre elas? Você sugere o uso de sufixos? Se sim, você poderia dar um exemplo?

— Kwadz

Para DDD, e se a lógica de cálculo de preços for complicada? Por exemplo, o preço é baseado na localização (imposto), informações do usuário (desconto na data de nascimento, desconto na associação), cupom, cartão de crédito (desconto especial no cartão de crédito) etc. Como podemos colocar essa lógica dentro da Orderclasse?

— 11108 Sher10ck

O agregado do seu pedido deve conter todas essas informações necessárias para fazer o cálculo. Porque com base na sua descrição, isso deve realmente fazer parte do agregado. Mas se a lógica se tornar realmente complexa e você precisar alterá-la, eu passaria a calculadora como um objeto para o construtor da entidade e deixaria que a entidade usasse a calculadora internamente para definir o preço.

— burzum

Anêmico ... o domínio ruim parece que está sofrendo de algum tipo de doença. Você não preferiria ser conduzido ?! sim!

— Matt Jenkins

Bem, os Objetos de entidade e de negócios são quase os mesmos, na maioria das vezes. Por exemplo, se você tem uma classe de produto e deseja expor uma propriedade que utiliza alguma propriedade existente na classe de produto e faz algum cálculo e a expõe. É bom no termo que, a lógica de criar essa propriedade permanece com a classe.

Agora, pode surgir a pergunta: onde ajustar sua classe de camada de negócios. Eu prefiro usar a classe de camada de negócios que possui alguma lógica para lidar com problemas de negócios. Por exemplo, no exemplo do seu produto, um problema comercial pode estar cobrando dinheiro usando um fornecedor de terceiros como o paypal.

Uma coisa importante a lembrar é que uma entidade sempre terá uma identidade, mas um objeto de negócios é uma entidade sem identificação. Por exemplo, o produto é uma entidade, mas o dinheiro não teria uma identidade. 1000 instâncias diferentes de dinheiro seriam iguais.

Sim. Se a lógica de negócios da propriedade depender das propriedades existentes no mesmo modelo, seria melhor adicionar a propriedade ao modelo. Isso ajudaria a perder o casal desnecessário com a camada de negócios para as propriedades calculadas.