È una cattiva pratica avere calcoli nel Presenter / Controller e Vista

"Best practice" è solitamente una mano breve per "qualunque cosa corrisponda ai miei pregiudizi". Non è una valutazione obiettiva, e casi specifici possono richiedere una partenza dalle migliori pratiche ...

Quindi, ecco i miei pregiudizi.

In primo luogo - lavora con qualunque sia la tua struttura e usa lo stile di sviluppo accettato. Ciò semplifica la comprensione dell'applicazione e di solito è il più grande contributo alle "best practice".

La seconda raccomandazione è "non ripeterti" (noto anche come DRY). Calcola quale bit di logica è responsabile del calcolo del prezzo totale e non lasciare che altro codice lo ripeta.

L'intero punto dei framework MVP / MVC è che la logica del dominio risiede nel controller; questa è una reazione alle applicazioni non strutturate che sono difficili da mantenere perché la logica del dominio si è diffusa in tutta l'architettura e ha reso difficile il debug, il test e la comprensione.

Nel tuo caso, immagina che il tuo "prezzo totale" si evolva nel tempo per includere i calcoli delle imposte. E costi di spedizione. E sconti basati sul prezzo del volume. Immagina anche di voler scrivere test unitari automatizzati per verificare che il calcolo del prezzo totale sia corretto. È davvero difficile da fare se un bit della logica è nascosto nei livelli controller / presenter.

Tutto questo è un motivo per inserire il calcolo del prezzo nel livello dominio e chiamarlo dal front-end come e quando ne hai bisogno.

Esistono delle eccezioni a questa regola, generalmente guidate da considerazioni relative a prestazioni e reattività. Se si desidera fornire un rapido feedback all'utente quando immettono i valori in un modulo, il roundtrip del server potrebbe essere troppo lento, pertanto potrebbe essere opportuno duplicare alcune regole sul client. Questo è spesso il caso della logica di validazione del modulo. Tuttavia, questo introduce la duplicazione, che è un onere di manutenzione, quindi fallo solo se sai di avere un problema di prestazioni e non puoi risolverlo in nessun altro modo.

È preferibile eseguire questo calcolo nel modello di dominio. Gli sviluppatori spesso trascurano entità commerciali plurali ... ProductCollection . TotalPrice

Detto questo, non penso che sia cattivo fare un semplice calcolo di raccolta come questo nel controller o nel presentatore. Assicurati di spostarlo in un secondo momento se i calcoli aggregati diventano più complessi o numerosi.

Tuttavia, per me, metterlo nella visione è completamente inaccettabile. Le viste non dovrebbero contenere alcuna logica, il loro unico lavoro è definire il layout di ciò che l'utente vede.

In casi come questo io duplica alcuni della logica sul lato client, solo come ottimizzazione e solo quando altrimenti influirebbe negativamente sull'esperienza utente. L'idea è che DDD non deve influire sull'esperienza utente in modo tale da risultare dannoso per il business.

Tuttavia, il calcolo finale viene eseguito ancora una volta nel livello Dominio, prima di mantenere le modifiche di un Aggregato.

C'è il rischio che, quando la logica aziendale sta cambiando, il codice lato client (il livello di presentazione in questo caso) è missallineato con il codice del livello Dominio ma tu, come sviluppatore, dovresti sapere se è accettabile.

Sì, è una cattiva pratica eseguire calcoli nel livello controller. Il livello controller è inteso solo per la delega della richiesta al livello di servizio. Il livello di servizio dovrebbe occuparsi di tutti i calcoli che abbiamo.