Devs, en esta ocasión les tengo un artículo muy interesante, y más si estás pensando en dar ese salto de desarrollador de software a empezar a aprender de arquitectura de software y diseño de sistemas. Sin duda esto es clave si quieres aspirar a posiciones senior así que te importará y mucho 😉
¿Qué es Bounded Context?
Un Bounded Context (Contexto Delimitado) es un límite explícito dentro del cual un modelo del dominio tiene significado y es consistente. Dentro de este límite, los términos, reglas, entidades y comportamientos tienen un lenguaje común, coherente y sin ambigüedad.
Y si te estás preguntando de dónde vino, debo decirte que es un concepto clave del enfoque Domain-Driven Design (DDD) y su objetivo principal es evitar malentendidos y acoplamientos innecesarios en sistemas grandes, donde distintas partes del software pueden usar las mismas palabras con significados diferentes.
Y entonces podrías preguntarme: Gerson son los bounded contexts indispensables en microservicios?La respuesta es un rotundo sí, porque los microservicios existen para separar responsabilidades de negocio y un Bounded Context justamente define los límites claros de un modelo de negocio y sus reglas.
Ejemplo sencillito pero real
Imagina que tienes una plataforma de cursos en línea, osea tu propio Udemy y decides utilizar microservicios.
Rápidamente vas a identificar al menos 3 microservicios:
| Microservicio | ¿Qué hace? |
| EnrollmentService | Maneja la inscripción a los cursos |
| PaymentService | Encargado de pagos y suscripciones |
| UserService | Administra usuarios y perfiles |
| CourseService | Gestiona los cursos, su duración y todo lo relacionado |
Como estás utilizando microservicios sabes que ocurre lo siguiente:
- Cada uno de ellos maneja su propia base de datos
- Tiene su propio modelo de dominio
- Tiene sus propias reglas de validación y del negocio
- Se comunica con otros microservicios ya sea por mensaje (asíncrono) o llamada HTTP (síncrono)
Eso es exactamente lo que define un bounded context, así que como ves la separación de un sistema en varios microservicios es debido a aplicar bounded context en cada uno de ellos.
Por supuesto, podrías no aplicar bounded context ya que al ser un principio no estás obligado a hacerlo o quizá no sabes cómo aplicarlo bien, pero esto sólo te traerá problemas.
¿Qué pasa si no aplicas bounded context?
Ineludiblemente vas a caer en los siguientes vicios:
- Terminarás compartiendo entidades, servicios o lógica de negocio.
- Cambiar algo en uno puede romper otro (esto es alto acoplamiento)
- No puedes escalar ya que evolucionar un microservicio rompe otro.
- En teoría tienes microservicios pero en la práctica es un monolito distribuído.
Recuerda dev: Todo microservicio debe ser la implementación de un Bounded Context.
Como puedes notar, no aplicar correctamente Bounded Context podría significar un dolor de cabeza para tu implementación de microservicios.
Bonus
Ya que he mencionado que "Compartir entidades, servicios o lógica de negocio" es un vicio, algunos devs me han preguntado:
Hey bravedev, entonces está mal que saque funcionalidad en común hacia una librería compartida y luego utilizarlas en varios microservicios?
Es una pregunta muy buena la verdad y ahora les respondo:
Está bien abstraer cosas en común que tendrán tus microservicios en un proyecto aparte de tipo librería de clases que luego puedes compartirlo por ejemplo mediante Nuget.
Sin embargo debes tener en cuenta que estas no deben tener entidades o modelos del dominio, ni deben tener lógica de negocio ya que cada microservicio debe tener su propia lógica y ser completamente independiente, mover la lógica para compartirla en varios microservicios rompe esta regla y aumenta el acoplamiento mucho.
Entonces qué sí se puede sacar aparte en una librería compartida?
Contratos como por ejemplo eventos que son consumidos en varios microservicios. También funcionalidad genérica, no personalizada ni atada a alguna entidad como por ejemplo la implementación utilizando generics del patrón repositorio o funcionalidad relacionada a configuraciones de nuestros microservicios que no incluyen lógica de negocio. En general cualquier cosa que puedas conseguir de nuget como un mapeador, una librería para aplicar patrón mediador, etc como notarás no están atadas a tu modelo de negocio ni a tus reglas, entonces sí pueden ser abstraídas y compartidas.
Como notarás, no es que no se pueda compartir nada entre microservicios, sino que hay que compartir lo correcto. Compartir lo técnico o los contratos es útil y saludable. Compartir el dominio es lo que debemos evitar para no romper la independencia del sistema.
La regla de oro es: Compartir contratos sí. Compartir lógica de negocio o modelos de dominio, no. 😉
Y bueno estimados devs, eso ha sido todo en esta ocasión, como podrás notar, estos temas son un poco más profundos y no hay mucho contenido hablando de esto así que espero que te haya servido mucho y ya sabes compártelo con todo tu equipo de ingeniería 🐿️🥳
Créditos de imagen de portada, basada en Foto de Yogesh Phuyal en Unsplash