Mostrando entradas con la etiqueta patrones-diseño. Mostrar todas las entradas
Mostrando entradas con la etiqueta patrones-diseño. Mostrar todas las entradas

lunes, 14 de febrero de 2022

3 patrones de diseño tipo wrapper ( proxy, adapter y decorator)

version en video:


https://youtu.be/bswx9qvuCdg

 

Estaba realizando una transformacion que necesitaba una cache que otra persona del equipo estaba haciendo(en paralelo), entonces pensé en un proxy que se encargara de cargar ese cache y retornare la información que necesitaba(desde un cache quemado en memoria) mientras otra persona hacia el desarrollo.

luego cuando se realizo la integración real la función del proxy se convirtió en transformar el string json que devolvía la cache a una clase que yo pudiera usar con sus valores. 

en la revisión del código me dijeron eso no es un cache, eso es un adapter. y tenían toda la razón aunque ambos son wrappers tienen sus diferencias, de hay nació este articulo.

Proxy

un proxy se usa para encapsular otro servicio o método(usualmente un servicio externo al no tenemos acceso directo) el proxy se encarga entonces de agregar algún comportamiento al método del otro servicio antes o después de llamarlo.con la salveda de que para que sea proxy debe tener la misma interfaz que el servicio origina ( osease que los métodos reciban y devuelvan el mismo tipo mediante una interfaz) por esto el error de arriba (el cache devolvía un string(cadena de texto) pero luego el proxy malo retornaba una clase). algunos ejemplo de proxy pueden ser.

  • virtual proxy: se encarga de cargar otro servicio solo cuando se vaya a usar ese recurso, para hacer un lazy load(carga perezosa) por que el otro servicio es pesado de subir y puede que no siempre sea necesario.
  • proxy de segurida: se usa para restringir acceso a cierto recurso a algún usuario.
  • proxy de loggeo: para loggear o imprimir en pantalla informacion que recibe o responde un servicio.

Adapter.

Es otro tipo de wrapper que se usa cuando no queremos la interfaz original del servicio base, en la historia anterior ese servicio no era un proxy sino un adapter pues estaba encargado de transformar un json como string del cache original en un clase kotlin. (este tipo de transformacion por ejemplo si el servicio original retorna un xml pero nosotros queremos integrarnos con json se les llama adapter)

imagen de: https://zh.wikivoyage.org/wiki/File:FTT102017.jpgFile:FTT102017.jpg - 来自维基导游的旅行指南

Decorator

este es el mas complejo de los 3, un decorador es como un proxy dentro de otro, dentro de otro ......

image de: https://www.publicdomainpictures.net/es/view-image.php?image=19582&picture=munecas-rusas

Muñecas rusas Stock de Foto gratis - Public Domain Pictures

 

la funcion del decorator es posibilitar encadenar comportamiento(en un orden personalizable) conservando la misma interfaz (decorar) y es frecuentemente usado en aplicaciones tipo stream.

en mi caso no entendía como funcionaba el decorator hasta que hice un ejemplo que se puede encontrar en https://github.com/chalimbu/decorator-java/tree/feature/solucionEjercisio1 aqui hice un decorador bobo para entender el concepto una clase que imprime en pantalla y unos decoradores para agregarle un mensaje(la fecha, una tag de error o info) al mensaje original por medio de decoradores que se construye en el Main.java. recomendado ver el ejemplo en el siguiente orden.

  •  https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/Logger.java
  • https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/decorators/SystemLogger.java
  • https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/decorators/SystemLoggerDecorator.java -> el decorador que sirve para encapsular los otros 3 siguientes.
  • https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/decorators/SystemLoggerDateDecorator.java
  • https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/decorators/SystemLoggerErrorDecorator.java
  • https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/decorators/SystemLoggerInfoDecorator.java
  • https://github.com/chalimbu/decorator-java/blob/feature/solucionEjercisio1/src/com/decorator/Main.java -> usando las clases definidas antes.

 estos 3 patrones tienen sus diferencias y su similitud que todos se encargan de servir de envoltura para otro servicio.

fuente:

la información viene de https://refactoring.guru/design-patterns/decorator donde se explica muy bien.

jueves, 22 de julio de 2021

Microservicios

notas del libro Microservices Patterns,Chris Richardson, capítulo 1 y 2.


Lo primero es entender que existen varias dimensiones en la arquitectura de software, es decir un sistema puede estar usando varias arquitecturas al mismo tiempo por ejemplo una arquitectura de micro-servicios con arquitectura hexagonal, o una arquitectura monolítica con arquitectura de 3 capas.para explicar esto el autor usa las 4+1 vistas y un escenario y un sistema de coordenadas x,y,z para representar las diferentes dimensiones de la arquitectura.


una arquitectura de micro-servicios es una arquitectura en la que la aplicación está generada por múltiples servicios independientes y desacoplados(cuando se dice que los servicios deben ser desacoplados en una arquitectura de micro-servicios esto significa que los servicios deben comunicarse por api y que cada servicio debe tener su propia base de datos)


y una arquitectura monolítica es una arquitectura de aplicación con un solo desplegable/ejecutable.

la arquitectura de micro-servicios tiene como es usual ventajas y desventajas que el autor explica en 3 partes

  1. las fortalezas de la arquitectura o lo bueno que trae
  2. el contexto resultante o como queda el sistema después de aplicar la arquitectura con que debilidades y que fortalezas
  3. y los patrones relacionados como un diagrama en el que se relaciona que otro patrón podría reemplazar a esta/cubrir sus problemas/ mejorarlo/o si este patrón es mejora de otro.

Para él es claro que si una empresa startup está empezando es mejor que esta empieze con una arquitectura monolítica y luego realiza el refactor a un arquitectura de micro-servicios. 


en qué punto hacer ese refactor es una línea delgada pero hay indicadores para reconocerlo por ejemplo.

  • si el equipo de desarrolladores son muchos +7 seguramente tiene mas sentido dividir las responsabilidades, para con esto balancear el costo de la comunicación entre tantas personas es muy improductivo
  • si la base de código es muy compleja y no le cabe en la cabeza a una sola persona, seguramente implica que no la deba trabajar una sola persona sino dividirla para diferentes partes las trabajen diferentes personas
  • cuando la cantidad de usuarios es muy alta y el escalamiento es muy complejo. por ejemplo por que una parte de la aplicación requiere mucha memoria por una in-memory database, otra tiene una red neuronal y requiere gpu etc. escalar es complejo porque cada instancia de la aplicación va requerir la suma de recursos que necesita la app como todo para correr

Incluso con estos indicadores mutar o irse del monolito a una arquitectura de micro-servicios es peligroso y puede salir mal en el peor de los casos se termina con un monolito distribuido un engendro que suma las desventajas del monolito y las desventajas de los micro-servicios. 


Al mismo tiempo y siendo complejo en cierto punto hace más sentido realizar micro-servicios porque la curva exponencial para realizar entregas en el monolito se vuelve insostenible, y muchas empresas que han escalado mucho muchísimo lo han podido hacer por las capacidades que les proporciona una arquitectura de micro-servicios.


el autor recomienda juntar micro-servicios con una arquitectura hexagonal(o de puertos y adaptadores) pues esta encaja bien con DDD( domain driven design) que al mismo tiempo encaja muy bien con la división de un servicio monolito en micro-servicios, en otras palabras un triángulo virtuoso.


y describe 3 pasos generales para cambiar de una arquitectura monolítica a una micro-servicios.


  1. reconocer los procesos que realiza la organización(estos se traducen usualmente a llamados o endpoint rest)
  2. Reconocer los servicios: a través de los procesos fundamentales de la organización oa través de subdominios identificados por DDD.
  3. identificar las api. es decir las interfaces de comunicación(de los servicios o atravesar de llamadas rest o eventos por mensajería)

yo creo que  plantear una arquitectura de micro-servicios es inevitable en cierto momento cuando las organizaciones crecen y su modelo de negocio tiene una base tecnología, y aunque tiene muchas complejidades lo único que queda es hacerlo lo mejor posible para no terminar solo con desventajas y/o más problemas