Ci sono decisioni tecniche che si notano solo quando sono sbagliate. Il calcolo dell'IVA è una di queste: se il catalogo ha un'aliquota sola, calcolarla sul totale del carrello o sommare i calcoli fatti riga per riga dà lo stesso identico numero, e nessuno si accorge della differenza. Il problema comincia quando il catalogo mescola aliquote — prodotti al 22% e prodotti al 4%, per dire, o casi ancora più di nicchia con aliquote agevolate su fasce specifiche — perché a quel punto le due strade possono produrre due totali diversi, entrambi "quasi giusti", nessuno dei due sbagliato per un errore di programmazione ma solo per come si arrotonda.
In DynamicShare l'IVA si calcola sul prodotto, riga per riga: ogni articolo nel carrello sa qual è la sua aliquota reale, letta da una tabella dedicata alle aliquote di archivio, non da un valore fisso impostato una volta a livello di sito. Il totale IVA dell'ordine è la somma di quei calcoli, non un calcolo separato fatto a posteriori sul totale. Sembra la scelta ovvia, scritta così. Non lo è quando il carrello ha sconti applicati a livello di riga, quantità diverse, e magari un buono sconto che si applica solo a una categoria di prodotti — a quel punto "calcolare l'IVA sul totale" richiede comunque di sapere come si è arrivati a quel totale, altrimenti l'unica aliquota che puoi usare è una media pesata che non corrisponde a nessuna aliquota reale scritta in fattura.
Il trait che si occupa di questo — lo chiamiamo internamente ComputesCartTotals — non è un pezzo di codice complicato. È un pezzo di codice che va scritto una volta sola, bene, e poi non toccato più, perché ogni piccola modifica rischia di spostare un arrotondamento di un centesimo su qualche combinazione di sconto e quantità che nessuno ha ancora provato. Ed è esattamente questo il motivo per cui vale la pena scriverne: non è una funzionalità che si vende bene in una demo, ma è il genere di dettaglio che, se sbagliato, si scopre da una segnalazione del commercialista del cliente, non da un test automatico.