Blockchain en Arquitecturas Hexagonales

Las aplicaciones que solo utilizan blockchain tienen una utilidad muy limitada debido a la limitada cantidad de datos que se pueden almacenar, su dificultad de acceso, o la nula interoperabilidad de la cadena. Todo esto provoca,  que mas bien pronto que tarde, sea necesario agregar más componentes a nuestra arquitectura. Hace algún tiempo ya que vi un esquema que encajaba blockchain en una arquitectura MVC, pero me pareció un poco forzado.

Así mismo, el software de negocio parece buscar nuevas arquitecturas mas allá MVC, en parte impulsados por el DDD (Diseño Dirigido por el Dominio),  que nos llevan a arquitecturas como la Hexagonal, (sobre la cual me gustaría escribir un artículo pronto) en la cual encaja perfectamente blockchain.

Lo primero que podemos hacer en un desarrollo agil con DDD es modelar el dominio, la lógica de las entidades de negocio, sin contar con como lo persistiremos. Con esto postponemos la decisión de donde almacenar las entidades hasta que tenemos suficiente información para realizar mejor esta decisión. Tendremos mucho más claro que va en el blockchain y que va fuera.

Las entidades que caigan dentro de Blockchain serán asociadas a adaptadores blockchain. Estos adaptadores le indicarán a las entidades del dominio si blockchain (y por tanto el resto de entidades que comparten dicha entidad) aceptan un cambio de valor (transacción) o no.

hexa.001

Entidades de dominio persistidas en blockchain

Este adaptador también funciona como mecanismo de entrada. Notificando a nuestras entidades de dominio los cambios realizados por terceras partes en el blockchain, recordemos que blochchain emite eventos de modo muy eficiente. Esto nos permite mantener nuestra memoria actualizda y agiliza el acceso a los datos enormemente.

Y aquí es donde debo hablar del patrón CQRS:  El trabajo para realizar consultas es muy distinto del trabajo realizado para actualizar los datos ¿por qué siempre nos empeñamos en ponerlo junto? (si, nos lo pidió POO en su día).

La paginación, filtrado, ordenación no tienen nada que ver con la validación, la transaccionalidad etc. Definamos  caminos diferentes para cada caso; eso es CQRS

Las consultas se pueden realizar sobre nuestras entidades en memoria, aunque tomando la precaución de acabar tomando el estado de las entidades del blockchain, pero podemos agilizar la busqueda, el filtrado, la ordenación, y la paginación sin acudir al blochchain en absoluto.

Lógicamente nos daremos cuenta de que estas instancias en memoria deben ser persistidas en algun almacenamiento que sirva de cache de busqueda, por ejemplo con Apache Cassandra. No hay problema, las entidades de dominio pueden tener varios adaptadores, de modo que mantener una cache de consulta rápida es fácil y limpio.

hexa.002

Updating a searching cache

Dos cosas me quedan por enlazar:

La primera es la lógica de blochchain. Ya sea un smartcontract o el comportamiento predefinido de la cadena, normalmente define transacciones que atañen a varias entidades. Pero no estamos haciendo POO. Tenemos una entidad  de dominio raiz (root domain entity) que es punto central para acceder todas a las entidades de un dominio, y justamente es lo que necesitamos. Desde aquí podemos acceder a nuestras transacciones blochchain sin forzar lo más mínimo el modelo, puesto que aqui es donde normalmente reside la funcionalidad que afecta a todos tipos de entidades de nuestro dominio.

Hemos construido nuestro blokchain como consecuencia de usar DDD, así que tenemos perfectamente contenido nuestro blockchain dentro de nuestro dominio.

¿Y que pasa con otros dominios? DDD viene a decir que entre dominios se envían mensajes, pero en la realidad a veces no es tan sencillo, y acabas necesitando transacciones distribuidas. Blochchain es un excelente motor de transacciones distribuidas entre dominios, especialmente Hyperledger, que permite que varias cadenas tengan transacciones enlazadas, simplemente colocando validadores comunes a ambas. (también se pueden enlazar contratos con Ethereum, el resultado es similar). Hemos conseguido de este modo transacciones distribuidas entre dominios de un modo sencillo.

Ejemplo: si tenemos el dominio cuentas corrientes y dominio reservas de vuelo, una reserva podría fallar al cambiar de estado y la causa sería “falta de fondos en cuenta corriente”. La transaccion ha fallado en un dominio distinto al nuestro pero para nosotros no hay diferencia con un fallo que hubiera podido producirse por causas de nuestro propio dominio como: “vuelo cancelado”, en ambos casos el adaptador de blockchain no valida la transacción

No solamente encaja estupendamente blockchain con DDD, si no que además vemos que obtenemos sinergias en forma de

  • Un acceso mas rapido y flexible en las consultas a blockchain
  • Una forma muy simple de obtener transacciones distribuidas para nuestras aplicaciones, que no impacta en el rendimiento (no hay bloqueos)
Anuncios