De la misma manera que lo haría normalmente, pero con más disciplina, diligencia y pruebas.
La estructura de datos JSON (o lo que sea) que obtenga de algún otro servicio será la misma, ya sea que esté clasificada en tipos reales o implícitos.
Lo mismo es cierto de Go.
- ¿Cuál es el tamaño estándar para Agile Team?
- Cómo conectarse remotamente a sus computadoras
- ¿Cómo se desarrollan los grandes proyectos?
- ¿Cuáles son algunas buenas herramientas automatizadas de ingeniería de software?
- ¿Cómo se calcula el 'tiempo medio entre fallas' (MTBF) para el software de la computadora?
¿Cómo podría confiar en que una aplicación Go podría funcionar, si no tiene clases?
Simplemente lo haces, y funciona bien.
En una aplicación JS, modelaría los objetos que espero usar dentro de mi DSL; pero como objetos, no como clases o cualquier otra cosa. Instancias de estructura pura.
A partir de entonces, escribiría convertidores que incluyan bolsas de datos indulgentes, y los convierta a formatos rígidos a toEmployee(data) , etc. Compondría esas transformaciones puras y rígidas en una transformación de orden superior, para poder tomar todo el árbol de entrada y llegar a un árbol de salida muy estrictamente definido, de mi especificación, y luego poner el árbol a través de la tubería para cualquier servicio, produciendo así el formato de salida esperado, o un montón de pruebas fallidas.
Pero incluso en un reino tan difícil como JS, no permitiría que los datos atraviesen el sistema hasta que estén en una forma que sea parte de mi DSL o una forma intermedia entre los objetos DSL. Mi sistema estaría trabajando en tipos que definí, a pesar de que no hay clases … … y los tipos de argumentos son plausiblemente dinámicos … … y los miembros de los argumentos son plausiblemente mutables.
Y Clojure ofrece mucha más seguridad que esto, por lo que es aún más fácil razonar.