Por que as pessoas armazenam o frete e o manuseio no cabeçalho da ordem e não em um item de linha

Deixe-me perguntar-lhe isto. Se eu pedir 100 itens e depois mudar de ideia e pedir para ter apenas 50 antes que o item seja enviado, o frete cairia? Em outras palavras, a remessa é uma cobrança por pedido que não será alterada, independentemente do pedido, ou calculada com base nos itens individuais do pedido. Se você enviar coisas pesadas, é provável que seja baseado nos itens pedidos e, portanto, armazenados lá. Se você enviar itens mais leves, provavelmente a cobrança será padrão por pedido e deverá ser armazenada na tabela principal.

Acho que o raciocínio é duplo para colocar o frete, o processamento, o imposto etc. como campos calculados no cabeçalho.

1. Os desenvolvedores podem preferir esse estilo. Tendo trabalhado em aplicativos legados, percebi que muitos desenvolvedores de meados dos anos 90 tendiam a usar um design de tabela simples com campos calculados.

2. Os projetistas do software podem não estar cientes de usar uma abordagem mais normalizada para design de software especificamente no domínio. Se eu estivesse apresentando uma execução da IU Shipping, Hanlding, Tax, geralmente são valores somados exibidos como parte do processo de totalização de pedidos.

De maneira semelhante, os autores do código não diferenciam entre um modelo de domínio e um modelo de exibição ou o aspecto de exibição do modelo de domínio. Assumindo que os dois estão strongmente acoplados, é compreensível.

Se eu fosse dar minha opinião sobre qual rota seria a melhor, eu usaria uma abordagem normalizada de fornecimento de frete, manuseio, impostos e outras taxas como itens de linha para reduzir os campos calculados no cabeçalho da ordem. Em seguida, eu os fornecia como um valor somado em um ViewModel, se necessário, mas apenas como um produto da exibição da interface do usuário, nunca como um método de armazenamento de dados.

Pense da seguinte forma: um único pedido de remessa envia vários itens para um único endereço. A partir dessa frase simples, você pode deduzir as relações de entidade entre os vários bits de dados. Um pedido de remessa tem um relacionamento um-para-muitos com os itens, portanto, o formulário de detalhes mestre. Por outro lado, um pedido de remessa tem um relacionamento de um para um com o endereço de remessa, então eles são parte do mesmo formulário e em um banco de dados normalizado eles farão parte da mesma tabela.