Esposizione di modelli di dominio su API

Questo è esattamente uno dei motivi per cui esistono DTO.

Il compromesso è che l'aggiunta di DTO rende la tua implementazione un po 'più complessa e quindi incline agli errori, come una mancata corrispondenza nel mappare l'oggetto dominio a un DTO. Usa i test unitari per questo!

Un'altra cosa che potresti fare con il tuo DTO e che nei servizi REST tende a essere trascurata è il trattamento dei dati ipertestuali per riferimenti, oggetti nidificati e possibili operazioni.

Fai riferimento a PoeaA di Martin Fowler: "[...] vale la pena ricordare che un altro vantaggio è quello di incapsulare il meccanismo di serializzazione per il trasferimento di dati sul filo. Incapsulando la serializzazione come questa, i DTO mantengono questa logica fuori dal resto del codice e forniscono anche un chiaro punto per cambiare la serializzazione, se lo desideri. "

link

TL; DR: Mi piace l'idea di separare le preoccupazioni della logica di dominio e il "cablaggio RESTful" attraverso DTOS, sebbene introduca un design più complesso.

Sebbene non sia l'intento principale di Data Transfer Objects , i DTO possono essere utilizzati per soddisfare questo problema in un modo alla porzione di dati di un modello di presentazione .

Come è stato sottolineato, questo potrebbe ingigantire il tuo design e qualcosa di così semplice come un campo aggiunto potrebbe richiedere cambiamenti a bolla attraverso i livelli aggiuntivi. Per questo motivo, è consigliabile verificare se fornire i metadati per descrivere la serializzazione dell'oggetto . In molte lingue, questo prende la forma di annotazioni specializzate che possono essere applicate agli oggetti del dominio per evitare la noiosa traduzione di DTO. Pacchetti come Jackson ( attraverso l'uso di Mixins ) spesso prendono quest'idea un po 'più lontano per separare completamente i tuoi metadati dal tuo modello di dominio.