Tanto si estamos tratando de convertir una arquitectura monolítica a una arquitectura de microservicios, como si estamos comenzando a plantear nuestra arquitectura desde cero, es muy importante analizar el dominio que tenemos delante. En el momento que desmontamos nuestro monolito hacia microservicios, uno de los mayores desafíos es definir los límites de estos cumpliendo el principio de única responsabilidad y es donde entra en juego el concepto de Bounded Context.

¿Cómo partimos en bounded context?

El concepto de Bounded Context nace con DDD (Domain Driven Design)  y es un concepto core de este enfoque. La idea principal de este concepto sobre todo aplica a modelos grandes donde necesitamos partir y delimitar en subdominios y contextos estableciendo la relación entre estos. Por ejemplo, no es lo mismo entender los atributos y la relaciones de una entidad como puede ser un Pedido o un Cliente, vista desde un enfoque de marketing o vista desde un enfoque financiero.

Es importante entender que una entidad como Pedido o Cliente tiene relaciones entre contextos diferenciados. Por lo que, es importante identificar estos subcontextos y para ello podemos ayudarnos con una herramienta visual que se conoce como Mapa de Contexto.

Extraido del articulo sobre Bounded Context de Martin Fowler (https://martinfowler.com/bliki/BoundedContext.html)

Básicamente, cuando planteamos este mapa de contexto partiendo todo el sistema en subdominios, comenzamos a identificar subsistemas que forman un sistema complejo. Dividiendo el sistema utilizando una estrategia de divide y vencerás, estaremos separando nuestro problema principal en pequeños subproblemas a los que dar solución, problemas que pueden ser resueltos con pequeñas piezas de software (microservicios).  

Estos contextos suelen tener su propio lenguaje de dominio, tienen gran cohesión entre los elementos que lo componen y lo ideal es que tengan un acoplamiento débil entre el resto de subdominios. De esta manera, comenzaremos a entender todas las relaciones, cómo puede encajar el modelo de datos y cómo interactúan entre ellos. Sin darnos cuenta, estamos planteando una primera aproximación a una arquitectura de microservicios.

A parte de establecer un lenguaje ubicuo, donde todas las partes involucradas establezcan un glosario de términos  que ayuden a la comunicación entre desarrolladores de software y expertos en dominios, es muy importante analizar en profundidad estos dominios y sus fronteras. De esta manera, podremos proponer la mejor arquitectura para el producto que deseamos construir. En caso contrario, podemos terminar diseñando una arquitectura con dependencias incoherentes entre servicios, un fuerte acoplamiento o interfaces mal planteadas.

Diseñando la arquitectura 

En el diseño de estas arquitecturas es importante identificar dos fases. La primera de ellas sería la fase estratégica, donde se plantea una estructura de la arquitectura con una visión Big Picture, orientada a garantizar que esta está centrada en cumplir con las funcionalidades impuestas por negocio. A posteriori, se comienza con una fase táctica donde se baja la arquitectura a a un modelo de dominio donde comenzamos a hablar de Entidades, Agregados, Servicios de Dominio o Eventos de Dominio. En este nivel de zoom, comenzamos a identificar las implicaciones técnicas y plantear las mejores soluciones. Empezamos a hablar en un lenguaje técnico y a identificar los distintos servicios que compondrán nuestro ecosistema planteando una arquitectura orientada a microservicios.

Es importante pasar por la primera fase, diseñando alrededor de las funcionalidades de negocio, y no solo desde la perspectiva técnica, que nos mueve a crear capas horizontales como acceso a datos o mensajería. Es importante sobreponer el negocio a la visión técnica, de esta manera probablemente partiremos los microservicios de manera que tengan un solo propósito bien definido, encapsulando el conocimiento de su dominio. 

Veamos un ejemplo

Imaginemos una organización que se encarga de la gestión de la competición de un deporte profesional. El core domain y el problema principal es la gestión de la competición, sin embargo, existen muchas áreas involucradas en toda esta gestión y en el que conceptos como Jugador o Partido, tienen mucho que decir, pero sus relaciones son bien distintas.

Por ejemplo, puede existir un departamento de audiovisual, en el que el interés del concepto partido son las equipaciones, sus colores y las marcas, para que todo esté en orden en las televisiones. Otro departamento, se puede encargar del control económico de los clubs, por lo que la visión del jugador que tienen, les interesan conceptos como contratos, movimientos del mercado, impuestos. Metamos en la ecuación a otro departamento que gestione las alineaciones para ver que no se incumplan con las normativas, de sanciones, cesiones o filiales.

Veamos este ejemplo plasmado en un diagrama de contexto, donde identificamos los tres contextos: Financiero, Competición y Audiovisual, y sus puntos de relación entre ellos: Jugador y Partido.

Conclusión 

Para finalizar, hacemos un recorrido por los distintos puntos del artículo sobre  la división de nuestro dominio en Bounded Contexts e identificamos los siguientes puntos clave que debemos de tener en cuenta:

• Descubrir en profundidad y aprender sobre el dominio del problema
• Desarrollar un lenguaje ubicuo y glosario de términos evitando confusiones
• Identificar los distintos subdominios y universos del problema
• Definir los contextos a partir de estos subdominios y representar sus relaciones en un mapa de contextos
• Contar con los expertos del dominio en todo el proceso de consultoría

Aún teniendo estos tips en mente, no existe una metodología concreta para plantear el diseño correcto para tu arquitectura. No existen herramientas, ni martillos dorados ni balas de plata. Es muy importante analizar detenidamente con una visión completa del negocio, de la arquitectura, los requisitos y los objetivos. La mejor herramienta que puede tener un consultor técnico es su propia experiencia tratando de modelar el comportamiento y, sobre todo, en la fase de consultoría con la ayuda de los expertos del dominio.

Referencias:

https://martinfowler.com/bliki/BoundedContext.html

https://docs.microsoft.com/es-es/azure/architecture/microservices/model/domain-analysis