Design Patterns y reactive microservices

Todos los que trabajamos en el mundo tecnológico hemos tenido la oportunidad de escuchar de este libro "Design Patterns".

Para hablar de este libro me viene una anécdota que tuve para la construcción de un mueble para explicar qué son los patrones de diseño ,imaginémonos que nos piden hacer una silla y debido a que no tenemos experiencia en hacer muebles en madera ,buscamos un experto.

Y este carpintero nos permite que ver todo el proceso de la elaboración de la silla,desde el tipo madera hasta la pintura que debemos escoger.

 Y vemos que este carpintero tenía ya en mente una serie de pasos a seguir para la elaboración del mueble , este conocimiento que había acumulado a lo largo del tiempo generalmente se llama experiencia.

 Da la casualidad que este carpintero trabajaba para el IKEA en Italia  lo que me llamo la atención es que tenia un manual de como armar el mueble pero también me mostró que había otro manual de como construirlo. 

 El carpintero me mostró una agenda suya donde tenía unos moldes de muebles para cocinas que se ajustaban a las diferentes marcas de cocinas italianas.

Este concepto de tener moldes para una serie de problemas ya antes resueltos se los puede usar en la informática.

Este libro es el resultado de la experiencia de Erich Gamma,Richard Helm,Ralph Johnson y John Vlissides ,ellos han acumulado experiencia en la resolución de problemas en informática y han creado un catálogo de posibles soluciones del mismo modo que la libreta del carpintero del IKEA y los muebles en las cocinas italianas son un catálogo de posibles soluciones.
Design patterns son un catálogo de soluciones que Jason MacDonald lo explica muy bien y sería aconsejable darle un vistazo antes de leer el libro de los patrones .
 

Por ejemplo cada vez que necesito hacer un programa que necesita conectarse a una base de datos y representar en estructuras por ejemplo en Java las tablas de la base de datos ,existe el "Design patterns" Data Access Object Pattern  nos puede ayudar.

La mejor manera de aprender a implementar estos patrones en tu proyectos es primero escribirlos y debugarlos para que se entienda la fuerza de cada uno de ellos ,te recomiendo que descargues de este link cada uno de estos patrones y cada uno de estos programas los corras y hagas el debug de cada uno de estos scripts y de ahí vayas al libro a leer la teoría ,he tomado los ejemplos de este sitio web y me ha parecido muy práctico y fácil de usar.

Este es el proyecto en Java en Eclipse con todos los ejemplos :

Proyecto Java de todos los Patrones de Diseno

Según mi experiencia en desarrollo de sistemas y la implementación de "Design patterns" es importante tener en mente algunas consideraciones antes de ponerse a desarrollar, es por esto que escrito esta serie de consejos en el momento de comenzar un proyecto :

 1-Antes de pensar como programador piensa como arquitecto y después piensa como un analista funcional ,solo cuando estos tres personajes lleguen a un acuerdo escribe codigo.

2- Un microservicio contiene un algortimo que soluciona un determinado problema pero necesitan tener una serie condiciones que la veremos a continuación :

• Quien va usar los microservicios y que permisos debe tener de lectura/escritura los usuarios que los usan .
• La cantidad de veces que será llamado los microservicios y la posibilidad de que sea llamado al mismo momento por tantos usuarios ,es importante al momento de diseñar los microservicios.
• Los mensajes de error deben tener un log que debe ser fácilmente leído para entender problemas del funcionamiento del sistema. 
• Isolar las actividades para la gestión de acceso a diversos  microservicios compartidos es importante ,el concepto de multi hilos  debe  ser  claro dónde aplicarlo en los procesos del sistema , y si deben ser asíncronos.
• Cada una de las actividades dentro un proceso de un microservicios deben considerar el concepto de transacciones para evitar problemas de inconsistencias de datos.

 3-Cada uno de estos microservicios deben ser parte de procesos que sean identificables y deben estar al interno de una estructura que permita una fácil  administración a los programadores en el momento de realizar cambios en los microservicios.

4. Se debe tener en cuenta  que los sistemas tienen una larga duración y los programadores se van de las empresas y la documentación no basta para que los nuevos programadores se integren rápidamente al proyecto.

Es por eso que la estructura de los sistemas deben hablar por si mismo,dicho de otro modo, la arquitectura del sistema debe ayudar a la curva de aprendizaje y design patterns ayudan a lograr este objetivo.

 Por ejemplo en una ocasión me toco modificar un sistema que gran parte del sistema estaba hecho en javascript con un framework que impedía realizar un debug y la parte backend estaba en java pero tenia sentencias reducidas booleanas  pero el momento de realizar cambios era difícil debido a que las reglas del negocio no estaba separada de la implementación .

En este proyecto para realizar un tarea de bug/fixes requería mucho tiempo de desarrollo ,es otro error arquitectural por que la parte funcional era muy dinámica y solicitaba tantas modificas en el sistema.

 5- Podemos verlo en modo jerárquico el diseño de sistemas , una mega estructura contiene procesos y al interno de estos procesos existen microservicios.

Muchas empresas trabajan con frameworks como Spring delegando gran parte del trabajo a estos frameworks que al interno de ellos se encuentran implementados Design patterns,pero debemos tener mucho cuidado que no todo los sistemas se resuelven con frameworks por ejemplo en una ocasión en una empresa me toco modificar un scheduler hecho en Spring boot ,este programa lo unico que hacia era crear un archivo de texto fruto de una query.

Aquí claramente hacer en un Servlets en lugar de usar Spring boot  hubiera sido una solución más óptima ,esto es un ejemplo de que los tres personajes no se reunieron hablar (programador,arquitecto y analista funcional) ,debe quedar claro que la implementación de los microservicios creará una estructura  ,donde se deben usar "Design patterns" para que la estructura final permita comunicar fácilmente a los objetos que se encuentran al interno de los microservicios y la evolución del negocio se adapte  a la arquitectura .

 Este proceso de adaptación es lo que nos brinda los "Design patterns", el problema es que no es fácil su implementación ,de este duro trabajo se encargan los frameworks pero en algunas ocasiones son cajas negras que te quitan control total a tu proyecto y es aquí el gran dilema en el momento de desarrollar un sistema,velocidad de desarrollo VS control del proyecto .

Fuentes bibliográficas :

Te aconsejo que para entender el concepto de microservicio reactivos pueden dar un vistazo al libro.

 "Building Reactive Microservices in Java Asynchronous and Event-Based

Application Design  Clement Clement Escoffier"  y este link te dará una idea general

 https://www.reactivemanifesto.org/

Dale un vistazo a este artículo para entender que es un Reactive MicroServices ,https://www.arquitecturajava.com/reactive-microservices-y-arquitectura/

 A lo largo de este texto usaremos el concepto de Framework y he tomado un texto de IBM para definir algunos conceptos en Java ,

"Un Framework es un marco de patrones de diseño para la rápida implementación de aplicaciones Java. El se basa en un patrón de diseño de mensajería que se utiliza para implementar muchos patrones de diseño bien conocidos, además de las capacidades SOA y ESB." 

Antes de entrar en el detalle es bueno tener una panorámica general de lo que veremos aconsejo buscar  este libro.

 "Modern Java EE Design Patterns Building Scalable Architecture for Sustainable Enterprise Development -Markus Eisele"

https://www.tutorialspoint.com/design_pattern/index.htm

http://www.mcdonaldland.info/files/designpatterns/designpatternscard.pdf
https://dzone.com/refcardz/design-patterns?chapter=1

Una carta a Yuval Noah Harari

En esta ocasión tratare de hacer una sinopsis corta de este libro gigantesco de Yuval, este historiador israelita que da una visión a muchos eventos históricos como la caída del muro de Berlín ,la globalización basándose en la ciencia .

Más que un historiador lo considero un divulgador científico -profético que hace previsiones de la humanidad.

Antes de escribir la carta he seleccionado algunas frases del libro que me han gustado ,este libro es un constante debate entre la ciencia y la religión:

1. La ciencia converge en un dogma universal, que afirma que los organismos son algoritmos y que la vida es procesamiento de datos.

2. La inteligencia se desconecta de la conciencia.

3. Algoritmos no conscientes pero inteligentísimos pronto podrían conocernos mejor que nosotros mismos. 

 Estos tres procesos plantean tres interrogantes clave, que espero que permanezcan en la mente del lector mucho después de que haya terminado de leer este libro:

 4. ¿Son en verdad los organismos sólo algoritmos y es en verdad la vida solo procesamiento de datos?

5. ¿Qué es más valioso: la inteligencia o la conciencia?

6. ¿Qué le ocurrirá a la sociedad, a la política y a la vida cotidiana cuando algoritmos no conscientes pero muy inteligentes nos conozcan mejor que nosotros mismos?

7.El poder es una estructura de datos ,El comunismos es un sistema de datos centralizados y el capitalismo un sistema de datos distribuido.

8. Del mismo modo como la publicación del libro de Charles Darwin de la evolución de las especies no ha hecho desaparecer la religión cristiana ,el experimento revolucionario de Daniel Kahneman del 2002 premio Nobel de Economía no ha hecho que el pensamiento liberal pierda fuerza en el mundo político.

9.A Uber no le interesa algoritmos con conciencia solo inteligentes ,los taxistas serán sustituidos como fue para los caballos y el carro .

10.Nuestra mente no está en la capacidad de analizar a gran velocidad patrones matemáticos y se debe hacer caso al viejo proverbio conócete a ti mismo ,no pierdas tiempo con la filosofía,la meditación o el psicoanálisis ,trata de establecer una conexión sistemática de vuestros datos biométricos  ,permiten que los algoritmos analicen tus datos y te den las ordenes de lo que tienes que hacer ,a esto se le llama Auto-conciencia numérica .

Mi estimado Yuval , te escribe un lector que ha leído dos de tus libros.

Y te debo decir que  en 600 páginas ha creado la base para previsiones de un futuro distópico como la película de Blade Runner y he sentido mucho miedo que tengas razón .

En 600 páginas  has intentado que pierda mi fe ,demostrando con experimentos científicos que el hombre carece de alma y que no existe Dios ,has buscado de convencerme a toda costa que el orden del universo no lo da Dios ,que no existe ninguna causa celestial a los acontecimientos del hombre.

Pero he resistido a la tentación de recibir a brazos abiertos la nueva religión de los datos para sustituir viejos libros de ficción como lo denominas a la Biblia o el Coran.   

El dilema entre el Yo narrativo y el Yo experimental de los experimentos de neurociencia cognitiva de tu libro no me dan paz .

Pero déjame decirte lo que me decía mi abuela ,ella me decía ,"Mijito ,se debe vivir bajo el temor de Dios".

Prefiero vivir bajo el temor de Dios que bajó un grupo de algoritmos que controlan mi vida,la ciencia es una nueva religión de datos,creo que has tomado la fuerza de escribir este libro para liberarte de tu odio hacia las instituciones religiosas pero déjame decirte que una cosa es religión y otra es la espiritualidad.

Saludos.