Se hai un'entità come in un'entità DDD (non ciò che viene generalmente definito un'entità in framework come il framework di entità), allora l'entità dovrebbe proteggere i suoi invarianti. Quindi usare l'entità come DTO è molto probabilmente sbagliato. Un DTO non ha dati di input non convalidati dall'utente e deve essere trattato come tale. Un'entità è costituita da dati convalidati in uno dei tipi di oggetto invarianti validi. Pertanto si dovrebbe avere una conversione tra un DTO e un'entità che converte un DTO convalidato in un oggetto entità dominio.
In molti casi, le persone li ignorano usando modelli di dominio anemici ( link ) dove le "entità" in generale non contengono alcuna logica e quindi inseriscono tutta la logica di protezione invariante ecc. nel codice esterno (e quindi hanno bisogno di controllare invarianti dappertutto). Questo può funzionare, ma secondo me porta a bug. Ma è qualcosa che accade praticamente ovunque - specialmente dal momento che molti framework incoraggiano questo rendendo molto semplice scrivere codice in questo modo. Questo è un po 'troppo male perché porta al modo più semplice / più veloce di codifica che non è quello che porta ai migliori risultati (se segui DDD che è) ...
Ma è anche importante riconoscere che in molti casi DDD potrebbe essere eccessivo. Se stai praticamente facendo un'applicazione CRUD (che in molti casi probabilmente lo sei), DDD potrebbe essere eccessivo per il tuo dominio. Ovviamente questo non significa che dovresti buttare via tutte le buone idee e andare semplicemente in "modalità tutto-nulla", ma in alcuni casi non preoccuparti di certe parti del DDD può essere la scelta giusta da fare. Il difficile trucco qui è, ovviamente, identificare se il tuo dominio è abbastanza complesso da giustificare DDD o se è abbastanza facile non morderti nel culo rinunciare a certe parti di esso. :)