Table of Contents
Recapitulemos. Nos situamos en Amsterdam, en la edición de 2018 del evento Domain Driven Design Europe.
En el primer artículo destaqué las dos primeras ponencias que más destacaron a mi parecer, la primera era la que trataba sobre “The sistemics of the Liskov Substitution Principle” expuesta por Romeu Moura donde destaco la relación entre Liskov y el principio de Interface Segregation y que los ejemplos dados estan todos desarrollados en Java en metodología Type-Driven Development.
Mientras que en la segunda ponencia sobre “Autonomy & Asynchrony: the key to design reliable systems” expuesta por Indu Alagarsamy cabe destacar que la La ponencia hace una reseña estructurada de los patrones para conseguir sistemas fiables, sin los costes prohibitivos del uso de transacciones distribuidas.
Seguimos con las ponencias del evento Domain Driven Design Europe.
Las ponencias más interesantes del evento Domain Driven Design Europe 2018 – parte 2
3). Functional and Algebraic Domain Modelling
Debashish Ghosh
El autor del libro “Functional and Reactive Domain Modelling” (Manning Publications) introduce los conceptos de su libro en la ponencia.
Se empieza definiendo Functional, que es la modelación usando los conceptos de funciones como mapas puros entre dominio y codominio.
Algebraic, por otro lado, refiere a la modelación de tipos (objetos) y ecuaciones entre los mismos (constraints), que representan la lógica de dominio, para llegar a una algebra abstracta, que es básicamente lo que estamos acostumbrados a definir como la interfaz de un servicio de dominio.
Mediante el uso de las abstracciones funcionales y el lenguaje universal de las matemáticas (en las abstracciones de la teoría de categorías), existe la clara ventaja que muchas de ellas vienen ya implementadas en las librerías estándar, como por ejemplo Scalaz, de la que el poniente es co-autor.
El resultado es que se escribe mucho menos código, y más robusto.
Cuando hablamos de Domain, el autor remarca que se refiere al Dominio en el espacio del problema, así que la operación de modelar es la de mapear el espacio del problema al espacio de las soluciones.
Un sistema no puede ser nunca “puro” en su totalidad, así que existen abstracciones para componer secuencialmente en presencia de side-effects (Monads).
El autor remarca la diferencia que existe entre effects y side-effects, en el sentido de que los effects pueden coexistir en código puro (por ejemplo la existencia o no de un valor), mientras que los side-effects implican interacciones del programa con otros entornos (desde el tratamiento de excepciones en el runtime de un lenguaje hasta la escritura a disco).
Teniendo algebras y operadores de composición a pesar de la presencia de side-effects es posible imaginar el uso de operadores de composición a más alto nivel, es decir, composición de dominios.
El viaje sigue, introduciendo los tipos algebraicos (suma y producto), y los higher-kinded types, como constructores de tipos, y los demás conceptos de la programación funcional.
La obra del autor, tanto en el libro como en la ponencia, es monumental.
Sin embargo, necesitamos exponer brevemente algunas de nuestras discrepancias relativamente al tipo de modelación propuesta:
- Pattern matching: consideramos que el pattern matching rompe la modularidad del sistema, sobre todo si está ejecutado sobre funtores o mónadas.
El exhaustivity checking del compilador de scala es simplemente un warning, y requiere el uso de sealed traits, que rompen el Open-Close principle.
El polimorfismo mediante métodos virtuales, en cambio, da un compile-time checking muy exhaustivo, como error de compilación, minimiza la lógica condicional, refuerza la encapsulación y deja los módulos abiertos a la extensión. - Abstraction first: los niveles de abstracción que conlleva la composición de tipos “higher-kinded” acaba produciendo muchos niveles de genéricos, y necesita recurrir a monad transformers.
Esto produce:- un nivel muy alto de stamp coupling
- una desventaja clara en la expresividad del dominio, y del código en general
Nosotros llevamos años trabajando en un acercamiento a la modelación funcional e algebraica muchos menos “extremo”, que llamamos Object-Functional.
Por lo que entendemos, esto va mucho más en la línea de como Martin Odersky definió el lenguaje Scala, pero sobre ello escribiremos en posts futuros.
4). Promise & Purpose: Why understanding Promise Theory can make you better DDD
Kiki Carter
Otra ponencia expuesta por miembros de la empresa Lightbend.
La poniente introduce la teoría nombrada como “Promise Theory”, y sus aplicaciones en los sistemas de información.
La teoría es suficientemente compleja como para ser tratada en una ponencia, y lo mismo vale para las aplicaciones.
En general, el contexto es un sistema compuesto por agentes independientes, como puede ser un sistema basado en actores (v. Akka o MS Service Fabric), o bien un sistema de microservicios.
La idea es:
- el flujo pasa de ser “imperativo“, como secuencia de comandos, a ser la aceptación de “promesas” hechas autónomamente por cada agente
- un agente sólo puede hacer promesas en base a los recursos manejados por él. Un agente que depende de otros agentes no está capacitado para hacer promesas, ya que la realización de las mismas depende de otros agentes o recursos no manejados por él.
Nos queda aún por profundizar la teoría y sus consecuencias, pero creemos que podemos extraer alguna conclusión previa:
- la teoría enfatiza la autonomía de servicios, que es uno de los pilares de la arquitectura orientada a servicio (SOA).
- formas de implementar dicha autonomía:
- un sistema asíncrono, orientado a eventos, permite que la operación de cada servicio es completamente autónoma
- el hecho de “prometer” sólo lo que es relativo a cada agente sugiere que se vea el agente/servicio como una enésima definición de “encapsulación”, a nivel de los datos/recursos manejados
- lo mismo vale a nivel de configuración. Sin duda el approach sugerido pasa por acercarse más a la programación y configuración declarativa, en oposición a la imperativa.
Fue un total de 2 dias llevados al máximo en el evento Domain Driven Design Europe, en los que tuve la oportunidad de conocer gente muy interesante en la industria y conocer nuevos puntos de vista. Me llevo nuevas herramientas y conocimientos para seguir indagando sobre la arquitectura de software y dar cada vez una mejor versión de software que funciona.
Si este artículo sobre evento Domain Driven Design Europe te gustó, te puede interesar:
Arquitectura de microservicios vs arquitectura monolítica
Scala generics I: clases genéricas y type bounds
Scala generics II: covarianza y contravarianza
Principio de responsabilidad única
Sobre Dioses y procrastinación
Arquitectura de microservicios
Simular respuestas del servidor con Nodejs
Suscríbete a nuestro newsletter para estar al día de los eventos, meet ups y demás artículos!
