¿Qué es, en referencia a DDD, un contexto acotado?

Al trabajar en el libro "Implementando el diseño impulsado por el dominio" de Vaughn Vernon, no he podido comprender bien qué es realmente un contexto acotado.

El libro define un contexto acotado como "un límite conceptual donde es aplicable un modelo de dominio. Proporciona un lenguaje ubicuo que es hablado por el equipo y expresado en su modelo de software cuidadosamente diseñado" (la sección de introducción de "Guía para este libro"). Esta definición haría que pareciera que un contexto acotado es el modelo y el lenguaje de un subdominio, donde ese subdominio puede ser el dominio central (lo que parece que debería denominarse "subdominio central", pero eso es otra discusión ...) Esto todavía deja cierta ambigüedad en cuanto a lo que proporciona un contexto acotado. ¿Es una agrupación de uno o más subdominios? Si solo un subdominio corresponde a un contexto acotado, ¿qué nos dice realmente el contexto acotado?

El capítulo 3 del mismo libro, sin embargo, se refiere a las técnicas de integración entre contextos limitados. Sin embargo, esto parecería implicar que los contextos limitados son en realidad sistemas de software o artefactos de alguna variedad.

Martin Fowler discute brevemente la idea de un contexto acotado ( http://martinfowler.com/bliki/BoundedContext.html ), pero en realidad no aclara el problema.

Al final del día, ¿qué es un contexto acotado? ¿Es una agrupación de subdominios? ¿El modelo y el idioma para un subdominio? La implementación de un subdominio? Sin estas respuestas, parece bastante difícil entender cómo descomponer un espacio problemático de la vida real en contextos limitados.

Los contextos y subdominios limitados existen en diferentes niveles.

Un subdominio es una parte del espacio del problema, es una partición natural del sistema, que a menudo refleja la estructura de la organización. Por lo tanto, la logística y las operaciones pueden separarse de la facturación y la facturación . Eric diferencia los subdominios centrales , de soporte y genéricos de acuerdo con su relevancia comercial en el escenario dado.

Los contextos son porciones del espacio de soluciones. Son modelos . Sería bueno tenerlos, reflejar la partición dominios-subdominios ... pero la vida no siempre es tan fácil. Y es posible que haya hinchado el dominio heredado que abarca todo o más contexto en el mismo subdominio (es decir, la aplicación heredada anterior, la aplicación de reemplazo que alguien está creando).

Para tener un contexto acotado , debe tener un modelo y un límite explícito a su alrededor. Exactamente lo que falta en muchas aplicaciones basadas en datos que usan bases de datos para compartir datos.

Otra forma, ortogonal, de verlo puede ser la siguiente. El lenguaje ubicuo , la condición especial donde cada término tiene una única definición inequívoca, no escala. Cuanto más lo amplíe, más se introducirá la ambigüedad. Si desea lograr modelos precisos e inequívocos, debe hacer que sus límites sean explícitos y hablar muchas pequeñas lenguas ubicuas, cada una dentro de un solo contexto limitado, con un propósito bien definido .

Las técnicas de diseño impulsado por dominio se utilizan para ayudarnos a crear modelos del mundo en el que vivimos. Estos modelos existen como ideas en las mentes de las personas involucradas en un proyecto.

Debido a que la telepatía todavía está en su infancia, estas ideas se comunican entre personas utilizando palabras y frases.

Las palabras y frases pueden ser ambiguas en el mejor de los casos. Para ayudarnos a reducir la ambigüedad, utilizamos 'contexto' para aclarar su significado.

Cuando las personas se sumergen profundamente en un proyecto de software que abarca años, parecen olvidar el contexto del que surgieron las ideas que se convirtieron en las palabras que se convirtieron en los nombres variables que se integraron en el código.

Los novatos llegan al proyecto y comienzan a usar y consumir su lenguaje. Quizás sean usuarios, quizás sean desarrolladores. Si no se les proporciona un contexto, crearán su propio contexto (y, por lo tanto, significado) a partir de su propia experiencia de vida.

Este contexto recién aplicado guiará cómo los nuevos desarrolladores refactorizan o desarrollan el código. Si aplicaron el contexto incorrecto, refactorizarán y desarrollarán el código en, quizás muy ligeramente, la dirección incorrecta. Las direcciones incorrectas, por leves que sean, pueden causar problemas mucho mayores en el futuro.

A mi entender, un "contexto acotado" es simplemente un "contexto aclarado" que se entrega a los novatos del proyecto para que no apliquen su propio contexto arbitrario para manchar nuestro modelo, maravillosamente perfeccionado.

Es un reconocimiento explícito, por parte del equipo, que this phrase, en el this part of the projectmedio exacto this thing(y no, como bien podría pensar that thing).

Así como es una buena idea marcar los límites entre su jardín y el jardín de su vecino. Usted especifica el límite explícitamente para que no se enoje cuando comienzan a cavar un macizo de flores en su césped perfectamente cuidado.

Eso es. Es una idea muy simple que es tan importante que se ha escrito mucho al respecto.

Entonces sí. Un contexto acotado es literalmente un límite, una 'cerca', que distingue entre el contexto de un subdominio del contexto de otro subdominio en un proyecto.

El modelo y el idioma de un subdominio están aislados de otros modelos e idiomas para evitar ambigüedades en el significado.

Pero si. El mundo no es tan simple.

Usted y el equipo deben ser rigurosos para cumplir con el contexto definido. Es realmente fácil ser perezoso y volver a imaginar el contexto para cortar esquinas durante la construcción de software.

Además, las cosas interactúan con otras cosas y los contextos limitados también deben interactuar entre sí. Entonces, hay varios patrones para describir cómo ocurren esas interacciones. Consulte el libro de Eric Evan, Capítulo 14, Diseño impulsado por el dominio, para conocer estos diversos patrones: Kernel compartido, Proveedor del cliente, Conformista, Capa anticorrupción, Formas separadas, Servicio de host abierto, Idioma publicado.

Básicamente, el contexto limitado define algunos límites tangibles de aplicabilidad de algunos subdominios. Es un área abstracta donde cierto subdominio tiene sentido, mientras que los otros no. Así que esto puede ser una charla, una presentación, un proyecto de código con límites físicos definidos por el artefacto.

En diferentes situaciones utilizo tres perspectivas diferentes, o metáforas del concepto de Contexto acotado.

Desde la perspectiva del tiempo de ejecución, representa los límites lógicos, definidos por contrato de un servicio donde se implementa el modelo. El contrato se puede representar como la API de este servicio o un conjunto de eventos que publica y consume. Desde esta perspectiva, el contexto limitado no tiene nada que ver con los límites físicos.

Desde la perspectiva de un experto en dominios, el contexto acotado es un área donde se implementan ciertos procesos de negocios, se aplica cierto lenguaje ubicuo y ciertos términos tienen un sentido claro, mientras que otros no. Entonces, no es más que un rectángulo dibujado en una hoja de papel o una pizarra.

Para un desarrollador de software, es decir, desde la perspectiva del código estático, un contexto acotado representa una forma en que diseñé mis modelos alrededor de los subdominios correspondientes. ¿Con cuántas bases de código se implementa un subdominio específico? ¿En qué conceptos consisten? ¿Qué conceptos son aplicables en cada uno de ellos? Es por eso que se dice que los contextos limitados pertenecen a un espacio de Solución.

Realmente me gusta este ejemplo del concepto de contexto limitado.

Otra pregunta importante (si no la más importante) es cómo identificar contextos limitados . Si lo hace incorrectamente, terminará con servicios habladores, imposibles de mantener y estrechamente vinculados , también conocidos como monolitos distribuidos .