Specification Pattern en .NET

Esta entrada es para que no se me olvide. Siempre que trabajo con árboles de expresiones me paso la primera hora mirando la documentación tratando de recordar las 2 malditas líneas que te permiten combinar 2 expresiones Lambda.

Los Microservicios requieren macrodiseño.

Respondiendo una pregunta en StackOverflow sobre el tema; me he dado cuenta que la cosa daría para una pequeña entrada.

Microservicios es la palabreja de moda. Antes de que la mayoría de empresas medianas en vías de desarrollo hayan podido siquiera empezar a implantar decentemente SOA y ESB's en sus procesos de negocio informatizados ya salta algún geek que te dice que eso esta out; que el camino a seguir son los microservicios.

Asúmelo y sigue

Tienes una base de datos relacional cuyas tablas tienen -todas- identificadores automáticos; no tienes modelada ninguna herencia del dominio; tienes restricciones contextuales que no se representan en el esquema de persistencia (relación uno a uno si una entidad es de un tipo o uno a muchos si es de otro tipo, así que ponemos uno a muchos y ya controlamos desde código que se cumpla), tus VO aparecen, desaparecen y cambian constantemente; la mitad de tu persistencia son meta-datos no relativos directamente al dominio de la aplicación; no tienes borrados en cascada; tus entidades tienen datos que son mutuamente exclusivos... y tantas otras cosas como estas que sé que tienes.

Dale la vuelta antes de decidir.

No, en este post, no voy a recomendar que se cuelgue uno del pie para que llegue más sangre a la cabeza, se oxigene mejor el cerebro y se gane un par de puntos de C.I.

El título de este post proviene de ver como, muchas veces, las decisiones en cuanto al diseño y desarrollo de un sistema de información se hacen al revés. Por esto, recomiendo que siempre le deis la vuelta a la solución que se os a ocurrido y la analicéis en profundidad para determinar si es una mejor solución.

Los resultados de estas decisiones desastrosas es lo que se llama "Gran bola de lodo" y estoy seguro que muchos de vosotros lo habéis sufrido en algún modo o lo estáis sufriendo ahora mismo.

La concurrencia y el estancamiento de datos no son lo mismo.

Hablando con un compañero de trabajo me he percatado que todavía hay quien no entiende la diferencia entre los problemas con el estancamiento de datos y los problemas con la concurrencia cuando se trabaja con persistencia. De hecho el problema no es sólo entender la diferencia de estos 2 conceptos; si no comprender también el proceso que debe seguir la aplicación para aplicar correctamente los cambios en una entidad persistida y con acceso concurrente.

Un puñado de Servicios Web NO es SOA

Me habían pedido que le pegase un vistazo a un nuevo proyecto de integración y al abrir la presentación del proyecto, en la tercera página, me encuentro con las letras SOA. ¡Imposible! me digo. SOA se basa en ofrecer servicios con bajo acoplamiento que se encargan de la orquestación y coordinación de procesos de negocio, los cuales pueden implicar uno o varios dominios.

Se de buena tinta que no se han definido es esta compañía dominios lógicos (por lo tanto no existen fronteras entre dominios), ni planificados procesos de negocio estándar, no hay coherencia ni contexto; por lo tanto no se pueden modelar servicios que coordinen ni orquesten nada. Ni siquiera existe un lenguaje ubicuo con el que entenderse. SOA no es un patrón arquitectónico tecnológico, es un patrón arquitectónico para modelar la organización lógica del negocio en servicios flexibles, escalables y sin dependencias; si no hay organización no puede haber SOA.

Cuando abrí el documento del catálogo de servicios mis sospechas se confirmaron. Lo único que hay es un puñado de servicios web que hacen cosas sueltas y completamente descontextualizadas.

No quiero poner en evidencia el equipo de desarrollo de la plataforma; estoy más que seguro que son gente lista y competente. No es su culpa. En las condiciones actuales es IMPOSIBLE montar una arquitectura orientada a servicios.

Procesos de negocio de larga duración.

Cuando se modela un sistema, el cual está constituido por un conjunto de procesos de negocio, no es difícil percatarse de que existen procesos de negocio que tienen una larga duración. Esto nos genera una situación en la que el flujo de trabajo se convierte en una máquina de estados intermedios desconectada en espera de los eventos para continuar hasta su resolución final.

Mantén el historial GIT limpio.

Prisas, despistes, inoportunos de última hora, dobles interpretaciones, gerencia inestable (en más de un sentido ;) ). Todas estas cosas, y muchas más, son las que provocan que acabemos con varios commits en el repositorio local de GIT para un work item que en un principio tiene bien definido el "Done" y sus fronteras. Esto genera un historial lioso e ilegible que no debería reflejarse en las ramas remotas. La mayoria de las veces, un ammend soluciona los líos; en otras se requiere una medida una tanto más drástica.

Supongamos que hemos generado 4 commits locales a partir de la rama remota para finalizar work item. En la rama remota lo único que interesa es el commit que refleja todas las modificaciones realizadas necesarias para el work item; por lo que antes de realizar el push debemos reescribir el historial de la rama local y "aplastar" (squash) todos los commits en uno sólo.

Por suerte, GIT nos permite reescribir el historial utilizando el comando rebase. Asumiendo el ejemplo anterior sólo necesitaríamos ejecutar el comando:

git rebase -i HEAD~4

y nos aparece un editor con los 4 últimos commits a partir de donde está la etiqueta HEAD. En este editor debemos marcar el primer commit con la opción "pick" y el resto con la opción "squash". Básicamente le estamos diciendo que combine los 4 commits en el primero.

El resultado final es un solo commit que contiene todos los cambios realizados para la finalización del work item. Ya sólo queda realizar el push a la rama remota sin más complicaciones.

Las cosas chulas de HTTP/2

Ya tenemos el draft 17 del protocolo y la cosa está bastante consolidada. También hay un buen puñado de implementaciones. Pero, ¿que podemos esperar a grandes rasgos de este nuevo protocolo por mucho que cambien cosas en los sucesivos draft? Os voy a contar, así a salto de mata, con lo que os vais a encontrar.

La API no cambia

HTTP/2 no introduce cambios en las cabeceras, códigos de estado, verbos, etc. Teóricamente, podrías sustituir la librería HTTP/1 que usas actualmente por una HTTP/2 y no deberías tener que cambiar ni una sola línea de código.

Esto no quiere decir que no existan mejoras en la API que agreguen nuevas capacidades y mejoras al protocolo, pero éstas son de uso opcional y, aunque recomendadas, su aplicación se puede posponer.

Request ligeros y baratos

Con HTTP/1, los request son caros y pesados. Tanto es así, que han surgido una gran variedad de técnicas para reducirlos, como puede ser el inlining , el spriting o el batching.

HTTP/2 reduce en gran medida esa pesadez usando multiplexación de varios mensajes HTTP a través de una sola conexión. Esto permite que utilizando una sola conexión abierta se puedan enviar varios mensajes al servidor y además éstas no se bloquean entre ellas.

HTTP/2 también comprime las cabeceras, por lo que nos ahorramos un montón de ancho de banda. Esto es genial para clientes de celulares que suelen tener limites de datos y para Single Page Applications (SPA) que realizan un montón de requests cuyo body suele ser muy pequeño (un par de Identificadores de entidades y poco más)

Cache pushing

Aunque el computo de tiempo de carga final sea el mismo, siempre queda mejor, de cara al usuario, una espera inicial más larga (app bootstrap) y que el proceso posterior, mientras se trabaja, sea más fluido.

HTTP/2 permite mandar datos al cliente explícitamente para su cacheo y futuro uso. También permite  al servidor invalidar o actualizar esa cache de forma proactiva.

Protocolo binario

HTTP/2 ya no esta basado en texto. Es binario puro. Esto minimiza la carga de procesamiento del request/response, ocupa menos ancho de banda y es más simple y menos dado a errores. El problema de la depuración se tendrá que solventar con nuevas herramientas. De momento, el sniffer de red más popular, WireShark,  ya tiene un plugin para esta tarea.

Y seguimos con los blogs.

Otro blog más que no hay que perderse.

Los chicos de Plain Concepts contándote todo lo que hay que saber sobre ASP.NET.

http://blogs.plainconcepts.com/aspnetspain/