¿Qué es Bounded Context?

La creación de grandes sistemas es uno de los grandes problemas que aborda el desarrollo de software. En el proceso de gestión de estos sistemas, emerge un concepto denominado bounded context. Este término proviene del domain – driven design o DDD, un enfoque centrado en el diseño que se basa en el dominio del problema que se quiera resolver.

En el artículo de hoy queremos explicarte qué es el bounded context y por qué te insistimos tanto en su uso dentro de las arquitecturas como los microservicios.

¿Qué es bounded context?

El bounded context es la separación de un modelo de dominio en diferentes submodelos más pequeños y manejables. Cada uno de estos submodelos se especializa e una parte específica de una aplicación, esto como medida para reducir la complejidad y mantener una organizción clara en sistemas grandes y complejos.

Cuando trabajamos con domain – driven design en el desarrollo de software, los modelos de dominio tienen una tendencia a crecer enormemente a medida que se van añadiendo funcionalidades. El bounded context (proviene de boundaries -> límites) nos brinda delimitaciones de área del sistema en donde un conjunto de reglas y términos específicos son consistentes. Cada bounded context exige su propio vocabulario y lógica de negocio y con esto se evitan confusiones en distintas partes de la aplicación.

Para entender mejor, pongámonos en contexto: Estás desarrollando un sistema de e-commerce en el que, por un lado, tienes un equipo que se enfoca en gestionar a los usuarios, esto es, alta, baja y actualización de dtos, y por otro lado, tienes a un equipoq ue se encarga de gestionar las órdenes de compra. Aunque ambos equipos trabajan en la misma aplicación, tienen contextos completamente distintos. El equipo de usuarios solo necesita saber qué un cliente puede hacer compras, mientras que no le interesa cómo se gestionan los detalles de la orden. Este aislamiento es precisamente una de las funciones del bounded context. Fácil, ¿verdad?

Uso del bounded context en microservicios

En los últimos tiempos el bounded context ha adquirido gran popularidad con la adopción de arquitecturas que se basan en microservicios. Dentro de estas, cada microservicio es representado en un contexto limitado que interactúa con otros a través de interfaces bien delimitadas.

Continuando con el ejemplo del e-commerce, en este caso podríamos tener un microservicio dedicado a la gestión de usuarios y otro a la gestión de órdenes. Ambos deberían estar aislados y tener cada uno su bounded contexto propio. Si sucede que un día quieres cambiar la lógica de negocio para la gestión de órdenes, esto no afectaría en absoluto a la gestión de usuarios, ya que cada contexto opera de forma completamente independiente.

¿Cómo identificar los bounded contexts?

Al usar bounded context debemos determinar cómo se debe dividir el modelo de dominio en contextos. Para lograr una separación adecuada debes usar:

1. Lenguaje ubicuo: el bounded context es definido por medio del lenguaje que se utiliza en el dominio. Si diferentes partes de un sistema hacen uso de términos distintos para hacer referencia a conceptos iguales, este es un indicativo de que deberían estar en contextos separados.
2. Límites organizacionales: En diversas ocasiones estos nos ayudan a definir los bounded contexts. Ya que diferentes equipos dentro de una empresa manejan diferentes partes de un sistema, esto facilita la identificación de los límites.
3. Modularidad: los bounded context deben ser siempre modulares, esto facilita su desarrollo y mantenimiento. El diseño modular adecuado nos va a asegurar que las dependencias entre contextos sean mínimas.

Relaciones entre bounded contexts

Si bien los bounded context están separados, existen momentos en los que n ecesitan comunicarse entre ellos. En el proceso de gestionar estas interacciones, el domain – driven design introduce dos conceptos, a saber:

• Context maps: Es una herramienta que ayuda a visualizar cómo los diferentes bounded contexts se relacionan entre sí. Es una especie de diagrama donde se muestran las conexiones entre los contextos y cómo se intercambia la información entre ellos.
• Anticorrupción layers: Para evitar que un contexto afecte negativamente a otro, se puede utilizar una capa de anticorrupción o también llamada anticorruption layer , que actúa como un intermediario entre los contextos. Esta capa traduce los datos y evita que los cambios en un contexto generen efectos indeseados en otro.

En Keepcoding estamos comprometidos con tu formación, por eso queremos brindarte información completa y de calidad por medio de nuestro bootcamp en cloud computing y devops, el cual te ofrece la oportunidad de adentrarte en el mundo laboral rápidamente. ¡Asegura una posición destacada en el mundo tecnológico e inicia ahora tu formación!