Es importante tenerla si decidimos usar las cartas para estimar el alcance de una feature y decidimos que pertenece a otro Bounded context o necesitamos colaborar con él.
Especificaciones
Como principal concepto, podemos decir que representa una unidad indivisible de negocio. Lo difícil de un Bounded context a veces es descubrir qué es indivisible y qué no lo es. Para descubrirlo debemos recurrir a actividades como el Event storming.
Para ayudarnos a decidirlo, podemos recurrir a sus características más concretas, que en este caso sería pensar en una unidad que pueda ser independiente del resto y autosuficiente. Su manera de comunicarse con los otros Bounded context es a través de eventos de dominio. Cuando algo importante sucede en el Domain, un Domain event se genera y sale al exterior. Ese Domain event puede ser de interés para nuestro Bounded context, y a su vez, nuestros Domain events pueden interesar a otros Bounded context.
Puede sonar extraño juntar el concepto de autosuficiente y que otros eventos alteren el estado de nuestros Aggregate. Un evento del exterior puede alterar el estado de alguno de nuestros Aggregate, pero eso no quiere decir que en si, nuestro Bounded context es autosuficiente, ya que la relación de información de los Aggregate que contiene son coherentes entre ellos.
Por eso a veces es complicado a simple vista ver los límites de un contexto.
Para organizar cómo se influencian los eventos entre los Bounded contexts, existen métodos como el Bounded context canvas junto con el Domain message flow modelling que propone Nick Tune.
Bounded context canvas example template
Domain message flow modelling example template
|
|