Acho que o raciocínio é duplo para colocar o frete, o processamento, o imposto etc. como campos calculados no cabeçalho.
-
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.
-
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.