Ho lottato con questo da solo. Ci sono casi in cui è opportuno utilizzare un DTO nella presentazione. Diciamo che voglio mostrare un elenco a discesa di aziende nel mio sistema e ho bisogno del loro ID a cui associare il valore.
Bene, invece di caricare un CompanyObject che potrebbe avere riferimenti ad abbonamenti o chissà cos'altro, potrei rispedire un DTO con il nome e l'ID. Questo è un buon uso IMHO.
Ora prendi un altro esempio. Ho un oggetto che rappresenta una stima, questa stima potrebbe essere composta da manodopera, attrezzature ecc., Potrebbe avere molti calcoli definiti dall'utente che prende tutti questi elementi e li riassume (ogni stima potrebbe essere diversa con tipi diversi di calcoli). Perché dovrei modellare questo oggetto due volte? Perché non posso semplicemente fare in modo che la mia interfaccia utente enumeri i calcoli e li visualizzi?
In genere non utilizzo DTO per isolare il mio livello di dominio dalla mia interfaccia utente. Li uso per isolare il mio livello di dominio da un confine che è al di fuori del mio controllo. L'idea che qualcuno inserisca le informazioni di navigazione nel proprio oggetto aziendale è ridicola, non contaminare il proprio oggetto aziendale.
L'idea che qualcuno metta la convalida nel proprio oggetto aziendale? Bene, io dico che questa è una buona cosa. La tua interfaccia utente non dovrebbe avere la responsabilità esclusiva di convalidare i tuoi oggetti aziendali. Il tuo livello aziendale DEVE eseguire la propria convalida.
Perché inserire il codice di generazione dell'interfaccia utente in un oggetto busienss? Nel mio caso ho oggetti separati che generano il codice dell'interfaccia utente separatamente dall'interfaccia utente. Ho oggetti separati che rendono i miei oggetti business in Xml, l'idea che devi separare i tuoi livelli per prevenire questo tipo di contaminazione mi è così estranea perché perché dovresti anche inserire il codice di generazione HTML in un oggetto business ...
modificare
Come penso un po 'di più, ci sono casi in cui le informazioni dell'interfaccia utente potrebbero appartenere al livello del dominio. E questo potrebbe offuscare quello che chiami un livello di dominio, ma ho lavorato su un'applicazione multi-tenant, che aveva un comportamento molto diverso sia dall'aspetto dell'interfaccia utente che dal flusso di lavoro funzionale. A seconda di vari fattori. In questo caso avevamo un modello di dominio che rappresentava i tenant e la loro configurazione. La loro configurazione includeva informazioni sull'interfaccia utente (etichette per campi generici ad esempio).
Se dovessi progettare i miei oggetti per renderli persistenti, dovrei anche duplicare gli oggetti? Tieni presente che se vuoi aggiungere un nuovo campo ora hai due posti per aggiungerlo. Forse questo solleva un'altra domanda se stai usando DDD, sono tutti oggetti di dominio di entità persistenti? So che nel mio esempio lo erano.