Bounded Context
Un aspecto crítico a la hora de implementar DDD es la correcta definición de los Bounded Context (Contextos Acotados en español). Esto nos permitirá, a su vez, definir los agregados y demás elementos de nuestro sistema. El Lenguaje Ubicuo juega un papel decisivo a la hora de definir cada uno de nuestros bounded context.
El Problema
Empecemos por definir que son los bounded context:
Son límites lógicos donde un dominio está totalmente definido.
Qué queremos decir con "el dominio"? El dominio es el universo del negocio con el que se está trabajando además de los problemas que quiere resolver. Por lo general, todo negocio tiene reglas, procesos y sistemas existentes que deben integrarse como parte de la solución. El dominio también son las ideas, el conocimiento y los datos del problema que se está tratando de resolver. La mayoría de las empresas tienen términos que tienen un significado específico dentro del contexto de su organización. Es probable que también tengan métricas, metas y objetivos que sean exclusivos de su negocio.
Perfecto pero, ¿cómo definimos nuestro dominio? La respuesta es fácil, usando el lenguaje ubicuo. Cada dominio tiene su propio lenguaje ubicuo que carece de sentido en otros dominios.
Por ejemplo, supongamos que estamos desarrollando una plataforma de venta de libros, cuando hablamos con negocio (ventas) nos comentan que un Cliente puede realizar Órdenes de compra que a su vez contiene ciertos Productos. Otro de los integrantes de negocio nos comenta que en soporte los Clientes abren Tickets relacionados con Productos que han comprado. Podemos ver que en el departamento de ventas hablan de Clientes, Órdenes y Productos, a su vez, en el departamento de soporte hablan también de Clientes y Productos además de Tickets pero no hablan de Órdenes. Al continuar con la conversación vemos que existen cada vez más términos no comunes entre la gente de soporte y la gente de ventas, es decir, cada uno usa su propia jerga o lenguaje de negocio, o para nosotros, su lenguaje ubicuo. Ahora que tenemos identificado cada lenguaje ubicuo podemos definir el dominio de cada uno, por ejemplo:
Observamos qué, tanto Clientes como Productos, están repetidos en ambos dominios. Cada uno, cuenta con una representación dentro de cada contexto. Un Cliente para el departamento de Ventas contendrá sus datos personales, su historial de compra, datos de pago, etc. Sin embargo, para el departamento de Soporte los datos de pago no son necesarios, pero si necesitará el historial de compra además del historial de tickets abiertos. Una misma entidad tiene varias representaciones dependiendo del punto de vista o del contexto en el que se encuentre.
La Solución
El modelo en todo proyecto es la solución al problema planteado por el negocio. Generalmente, representa un aspecto de la realidad o algo de interés, y se centra en el conocimiento de un problema específico, que se simplifica y estructura para proporcionar una solución. El modelo de dominio es su conocimiento organizado y estructurado del problema.
El modelo de dominio debe representar el vocabulario y los conceptos clave del problema, también debe identificar las relaciones entre todas las entidades dentro del alcance del dominio. El modelo de dominio debe actuar como una descripción clara del problema que se está resolviendo y la solución propuesta. Es extremadamente importante que todas las partes interesadas del proyecto contribuyan al modelo de dominio para que todos comprendan los conceptos clave, las definiciones del vocabulario y, cómo se aborda y resuelve el problema.
Conclusión
Un bounded context es una división lógica donde un problema de negocio y su solución están totalmente definidas. Nos permite dividir un gran problema en problemas mucho más pequeños, para que podamos concentrarnos en aspectos particulares de la aplicación mientras ignoramos todo lo demás. Podemos usar un lenguaje coherente en torno a ese problema específico, para que todos tengamos una definición clara de cada uno de los términos importantes.
Por lo general, ciertos objetos en una aplicación tienen diferentes definiciones en distintos contextos. Al dividir la aplicación en bounded context, nos aseguramos de que las líneas entre cada contexto estén claramente definidas, para que la terminología en torno a las ideas y conceptos de la aplicación se entiendan claramente.