¿Cómo evitar la duplicación de estructuras de datos cuando partes de una aplicación están escritas en diferentes idiomas?

Como ejemplo, supongamos que está escribiendo una aplicación en Java .

Su aplicación se comunica con un servidor API escrito en Python .

El servidor Python se comunica con una base de datos SQL .

También tiene un sitio web para su aplicación escrito en JavaScript .

Con 4 idiomas diferentes, es fácil terminar repitiendo esencialmente las mismas estructuras de datos 4 veces diferentes.

Por ejemplo, un Usertipo podría verse así (pseudocódigo):

type User {
  integer id;
  string name;
  timestamp birthday;
}

Cada parte del proyecto necesitaría algún tipo de representación para User. Las partes de Java y Python necesitarían dos classdeclaraciones diferentes . La base de datos necesitaría una Userdeclaración de tabla. Y el sitio de front end también necesitaría representar un User.

La repetición de este tipo 4 veces diferentes realmente rompe el principio de no repetirse . También existe el problema de que si Userse altera el tipo, estos cambios deben repetirse en cada parte diferente del proyecto.

Sé que la biblioteca protobuf de Google ofrece un tipo de solución a este problema en el que escribes una estructura de datos utilizando una sintaxis especial, y luego la biblioteca genera una declaración de estructura para ti en múltiples lenguajes de programación diferentes. Pero esto todavía no se ocupa del problema de tener que repetir la lógica de validación para sus tipos.

¿Alguien tiene alguna sugerencia o enlaces a libros / publicaciones de blog sobre esto?

Tu no. O realmente, no deberías.

Si piensa en la aplicación, su servidor y su sitio web como contextos separados, entonces tiene sentido que existan estructuras duplicadas. Razones por las cuales podría ser algo bueno:

• Las estructuras son similares, pero no iguales. Incluso si el 90% de la estructura es la misma en todos los contextos. Es el 10% que le dará dolores de cabeza masivos.
• Los patrones y las implementaciones pueden ser diferentes. Cuando se utilizan diferentes lenguajes y marcos, se vuelve demasiado difícil tener la misma implementación en todos ellos
• Las estructuras compartidas se convierten en una dependencia, que necesita ser administrada. Tener una dependencia compartida complica enormemente el desarrollo, ya que un cambio que es excelente en un contexto es abismal en otro. Se necesita mucho esfuerzo para coordinar el desarrollo de esta dependencia compartida
• Diferentes contextos tienen diferentes implementaciones. Incluso si logra compartir las mismas estructuras de datos y el mismo código de validación en todos los contextos, puede suceder que se implemente una nueva versión de un contexto mientras que otros están en la versión anterior, por lo que las situaciones en las que hay desincronización en las versiones aún deben Ser dirigido

Si bien el principio DRY es sorprendente, creo que compartir estructuras de datos en contextos o capas crea más problemas de los que resuelve. Especialmente si el proyecto crece lo suficiente como para que diferentes personas trabajen en diferentes contextos.

Creo que @Euphoric enumeró un par de buenas razones para no duplicar su código. Sin embargo, si debe hacerlo, le recomiendo usar la generación de código.

Encuentra la forma canónica de los datos

Para hacerlo de manera efectiva, primero debe descubrir cuál es la forma canónica de los datos. ¿Es su esquema SQL o clases en su programa Java?

Derivar (automáticamente) las otras formas de él

Después de eso, idee una forma de generar todas las otras formas a partir de la canónica. Por ejemplo, suponiendo que su forma canónica es el esquema SQL, puede generar código JavaScript, Java y Python fácilmente (SQL se analiza fácilmente y es un buen candidato para la fuente canónica).

Acomodar las diferencias

Debería ser fácil marcar las secciones del código generado como "no tocar", de esta manera se acomodarían las diferencias requeridas entre todas las diferentes representaciones (por ejemplo: el código personalizado que escribió para su interfaz JS y back-end Java) que necesita ser preservado a través de regeneraciones.
Tome un ejemplo de Git; Cuando se abre un editor para permitirle introducir un mensaje de registro en el archivo ya contiene un texto, pero tiene el # -------- >8 --------marcador para saber donde sus extremos contenidos, y donde su empieza texto generado automáticamente.

Aún así, si puedes, evita esa duplicación. Es un PITA, incluso si la mayor parte de su código se genera automáticamente.

Esta respuesta es un poco como una historia en lugar de "aquí hay algunas mejores prácticas": lo que describí es exactamente lo que hice una vez cuando tuve el mismo problema que usted y necesitaba tener los mismos datos representados en diferentes partes del sistema (o, más bien, en dos sistemas diferentes).