Mapeamento vs. camada de serviço, ou posição lógica de negócios

Question

Eu tenho um produto e uma coleção de pagadores. Os pagadores podem pagar pelo produto de três maneiras diferentes, mas definir manualmente a porcentagem, por receita dos pagadores ou pelo valor dos respectivos participantes. Como o produto é pago é determinado por uma enumeração do produto.

Na minha camada de persistência, obtive três classes, produto, pagador e productomanalmente pago, que é uma aula de muitos para muitos entre produto e pagador se o produto for pago manualmente, especificando a porcentagem que cada pagador terá que pagar.

Como devo mapear isso para a visualização? Eu gostaria de ter uma nova classe muitos para muitos (que consistiria em uma referência ao pagador, uma referência ao produto e ao valor exato que o pagador deve pagar)?

Eu acho que o cálculo deve ser feito na camada de serviço, mas a camada de serviço deve retornar uma versão ViewModel/DTO do produto/pagador com uma nova classe muitos para muitos, ou isso deve ser tratado depois? Se deve ser tratado depois, a entidade deve conter uma lista dessa nova classe muitos para muitos, mas ser ignorada na camada de persistência?

Answer 1

O DDD pode sugerir que você deve adotar uma linha de pensamento que se concentre antes de tudo no design do modelo de objeto, em vez do modelo ER/dados. Vejo que você pensou em como o modelo de dados deve parecer (com a tabela muitos para muitos, etc.), mas talvez você deva considerar como o modelo de objeto pode parecer primeiro. Então, como esse modelo de objeto reflete o domínio (lógica de negócios, comportamento comercial), pense em como você pode mapear esse modelo de objeto para o banco de dados.

Por exemplo, pode fazer mais sentido devolver um produto com uma coleção de pagamentos. E cada pagamento tem um link para a entidade do pagador. Dependendo do seu design, o link do pagador pode ter cópias das informações do pagador que você deseja acessar ou talvez esse link saiba como carregar a entidade do pagador completa com as informações/valores necessários. Além disso, cada instância do pagador pode ter uma coleção de pagamentos (o mesmo tipo de classe acima?) Que link de volta ao produto.

Esse design faz melhor uso dos diretores do OO e descreve o domínio melhor do que as maneiras pelas quais um banco de dados relacional pode. Além disso, esses objetos podem ser mais fáceis de manusear nos serviços e camadas da interface do usuário, pois sua estrutura de objetos nativos já fornece logicamente com as coisas que você precisa. ou seja. Um produto tem os pagamentos, que têm o pagador, etc.

Sou razoavelmente novo no DDD pensando em mim mesmo. E antes do termo DDD assustar você, dê uma olhada nisso Versão resumida do livro de Evan. É uma leitura leve e gratuita para download. Pode apenas dar a você as jóias que você estava procurando.