Da quello che ho capito, il suo punto è che gli oggetti di dominio non mapperanno in genere 1 a 1 ai DTO, nel senso che non avranno tutte le stesse proprietà. In effetti, gli oggetti dominio possono avere pochissimi getter e setter; potrebbero persino non averne affatto. Questo è legato al principio "tell, do not ask": se le responsabilità sono distribuite correttamente attraverso le classi, gli oggetti del dominio avranno pochissima necessità di estrarre dati gli uni dagli altri per ottenere qualcosa. Invece, chiameranno per lo più metodi l'uno sull'altro. Ora, mentre puoi usare librerie di tipo Automapper per copiare dati da DTO agli oggetti del dominio in uno scenario del genere, il punto dell'autore è che ciò richiede una configurazione abbastanza complicata, che sconfigge lo scopo di avere un automapper.
They can perform the mapping of course, but that would require setting up quite sophisticated mapping rules which diminishes the value of having the automapper in the first place.
Se il design dei tuoi oggetti di dominio è influenzato dal desiderio di supportare la semplice automapping, allora interromperà l'incapsulamento introducendo getter e setter che non sono realmente necessari. Questo potrebbe introdurre problemi con la convalida. Ad esempio, senza considerazioni di automapping, gli oggetti di dominio possono essere progettati in modo tale che non sia possibile richiamare un metodo o una proprietà e far finire l'oggetto in uno stato non valido quando il controllo ritorna al chiamante. Se si introducono getter e setter e un metodo Validate (), diventa possibile che un oggetto si trovi in uno stato non valido tra una chiamata a un setter e una chiamata a Validate (). Questo può o non può essere OK - come tutto il resto, è un compromesso.