Come evitare DTO su un'applicazione client / server?

Vorrei utilizzare i bean DRY sulla mia applicazione client-server (DRY: Dont Repeat Yourself). Non è un problema per me se è strongmente accoppiato: so che il mio DTO avrà la stessa forma dei bean di database (classe Entity in JPA). Il DTO ha il vantaggio di perdere l'accoppiamento tra un'applicazione, ma se sono copiati dal modello di database c'è una prima duplicazione, e poi sul mio schermo, io uso specifici bean (javaFX bean) in modo che lo schermo non possa usare direttamente un DTO, quindi c'è una seconda duplicazione. Il problema è in Java, ma lo stesso problema di dipendenze con dipendenze diverse tra client e server potrebbe apparire in tutte le lingue.

Ecco i dettagli della mia situazione:  - Backend Spring con dipendenze di ibernazione  - Comunicazione HTTP con JSON  - Frontend javafx con dipendenze oggetto osservabili

Lo scopo della mia architettura è che ogni richiesta di database serializzi un bean di modello da un database, e sul lato client deserializzi uno screen bean, usando JSON come formato intermedio.

Voglio usare una dipendenza comune tra il mio client e il mio server, in questo progetto comune voglio definire un oggetto comune per definire il formato Jackson tra client e server, e ho molte opzioni:

1. usa DTO: quindi copio i dati dall'oggetto Entity dal database con la stessa struttura, quindi copio questi dati su un javaFX Bean con gli stessi attributibutes, ma che è osservabile. Ci saranno 3 classi che rappresentano la stessa entità

   • modello - > Copia DTO sul back-end
   • DTO trasferito su HTTP
   • DTO - > Copia dello schermo su frontend

2. Serializza il bean del modello e deserializza il de screen bean assicurando che entrambi i bean possano essere serilizzati nello stesso formato JSON usando solo il test di junit.

   • modello su back-end senza trasformazione
   • modello trasferito su HTTP
   • modello - > Schermo deserializzato su frontend, la compatibilità con la struttura JSON non è garantita

3. Fai come in 2. ma usa un'interfaccia comune per essere implementata sia da bean di modello che da screen bean. Ma tutti i bean devono implementare un'interfaccia, non solo l'oggetto root del JSON, quindi c'è la duplicazione della struttura (tutte le classi duplicate in interfacce)

   • modello su back-end senza trasformazione
   • modello trasferito su HTTP
   • modello - > Schermo deserializzato su frontend, struttura JSON garantita con interfaccia

4. Usa il bean dei modelli come DTO: ma il client avrà una dipendenza inutile JPA

   • modello su back-end senza trasformazione
   • modello trasferito su HTTP
   • modello - > Schermata copiata sul frontend, dipendenze sul modello implicano dipendenze sulle annotazioni JPA

5. Usa lo screen bean come DTO: ma il server avrà delle dipendenze javafx, che potrebbero mancare da JDK in una versione futura (post java 11)

   • model- > Screen bean copiato sul backend con dipendenze agli osservabili di javaFX
   • screen bean trasferito su HTTP
   • screen bean deserialized su frotnedn, nessuna trasformazione.

Per rispettare il principio POLA, farei il classico "1". con DTO, ma non è davvero ASCIUTTO.

Ecco le mie domande:

• DTO è la soluzione più attesa per i futuri sviluppatori? (Voglio manutenibilità per la mia soluzione)?
• È ammesso avere una dipendenza inutile per condividere gli stessi oggetti: entità o screen bean?
• Possiamo contare su JSON per trasformare un oggetto in un altro? O dovrei avere una libreria projet comune tra il mio client e il mio server?