¿El desacoplamiento supera a DRY en REST?

Estoy creando una API REST para exponer la mayor parte de la funcionalidad de una API Java existente. Ambas API son para uso interno dentro de mi organización; No tengo que diseñar para uso externo. Tengo influencia sobre ambas API pero estoy implementando la REST. La API de Java continuará utilizándose para aplicaciones locales (no está "retirada"), pero la API REST se utilizará para un nuevo desarrollo significativo.

Algunas de las clases API de Java son simplemente datos (beans con propiedades, captadores, establecedores). Y al menos algunos de estos tienen sentido transmitir (de alguna forma) a través de la API REST como datos (que se ordenarán en XML o JSON). Por ejemplo, una clase que almacena información sobre una máquina servidor. Me enfrento a la siguiente opción para estas clases de datos: Do I ...

1. exponer la clase Java original (o una subclase) directamente en la API REST, o
2. hacer una nueva clase de transferencia de datos (patrón DTO) específicamente para la API REST?

De cualquier manera tendré clases de transferencia de datos REST; la pregunta es si hacer anotaciones en los originales o crear nuevos (que pueden ser copias cercanas de los originales). Puede haber otras opciones, pero me enfocaré principalmente en esas dos.

Argumentos para el # 1:

• SECO (no te repitas)
• Más rápido de implementar
• Más fácil de actualizar API REST

Argumentos para el # 2:

• ¿Qué sucede si la API REST necesita ser versionada por separado de la API Java? (Esto es algo probable).
• ¿Qué sucede si hay cambios significativos en las clases de datos de Java, como la eliminación de propiedades, la adición de comportamiento o cambios en la jerarquía de clases? (Esto también es algo probable).

La conclusión es que parece una compensación entre DRY (# 1) y desacoplamiento (# 2).

Me inclino por comenzar con el n. ° 1 y luego, si surgen problemas para pasar al n. ° 2 más adelante, siguiendo la guía ágil de no construir lo que no puede demostrar que necesita. Es una mala idea; ¿Debo comenzar con el # 2 si creo que puedo terminar allí de todos modos?

¿Hay argumentos / consecuencias importantes que faltan en mis listas?

Buena pregunta, simplemente, desacoplar. Ese es el camino a seguir aquí, no quieres estar atado a la versión de Java.

Hay un escenario que no desacopla: si su tecnología permitirá que se envíen objetos no específicos del tipo a través del cable, es decir, si puede usar los objetos java actuales ahora como YAGNI, y el reemplazo por otro diferente el tipo que personalice será un simple complemento que no romperá nada debido a que la información de tipo se transfiere por cable. Entonces, básicamente, si la información de tipo no cruza el cable, podría YAGNI en esto.

Solo tenga mucho cuidado y esté atento para que cualquier actualización de su versión de Java no cambie ninguno de estos objetos. De lo contrario, solo desacople ahora y no se preocupe por eso, supongo que depende de cuánto tiempo tenga si tiene una opción.

Sin embargo, si la información de tipo atraviesa el cable en su protocolo, entonces una introducción plana de nuevos tipos cuando cambian los tipos de Java subyacentes puede no ser posible y puede ser un esfuerzo mayor. Si ese es el caso, ir a YAGNI ahora significa acumular deuda técnica y riesgos relacionados con su tecnología subyacente.

Personalmente, simplemente me desacoplaría ahora.

Además, DRY no juega con esto porque no escribió las piezas subyacentes, por lo que no está duplicando el código y, por lo tanto, no tendrá los dolores de los errores repetidos en todo momento, lo cual es la principal preocupación de DRY (y la mantenibilidad general problemas que nuevamente no tendrá porque no tiene duplicados para mantener)

Los argumentos principales para el n. ° 1 son la facilidad de implementación y las actualizaciones, pero ¿cumple con sus requisitos?

En sus argumentos para el n. ° 2, indica que la API de Java y la API REST pueden cambiar de forma independiente. Esto significa que son preocupaciones separadas y que no te estás repitiendo al usar clases separadas. El hecho de que dos cosas se vean iguales no significa que sean iguales.

Su API REST no tiene que seguir la misma estructura que su modelo de datos

Al implementar REST, asegúrese de crear una API externa intuitiva y luego asigne esto a sus clases de modelo de datos internos. Esto le permite cambiar cada uno independientemente del otro, lo que lleva a API que pueden durar décadas .

Por lo tanto, el desacoplamiento es el camino a seguir aquí.