O que, em referência ao DDD, é um contexto limitado?

Ao trabalhar no livro "Implementing Domain Driven Design", de Vaughn Vernon, não consegui entender bem o que é realmente um contexto limitado.

O livro define um contexto delimitado como "um limite conceitual onde um modelo de domínio é aplicável. Ele fornece uma linguagem onipresente que é falada pela equipe e expressa em seu modelo de software cuidadosamente projetado" (a seção de prefácio "Guia para este livro"). Essa definição faria parecer que um contexto delimitado é o modelo e a linguagem de um subdomínio, onde esse subdomínio pode ser o domínio principal (que parece que deve ser chamado de "subdomínio principal", mas é outra discussão ...). Isso ainda deixa alguma ambiguidade quanto ao que um contexto limitado fornece. É um agrupamento de um ou mais subdomínios? Se apenas um subdomínio corresponde a um contexto limitado, o que o contexto limitado está realmente nos dizendo?

O capítulo 3 do mesmo livro, no entanto, refere-se às técnicas de integração entre contextos limitados. Isso, no entanto, parece implicar que os contextos limitados são realmente sistemas de software ou artefatos de alguma variedade.

Martin Fowler discute brevemente a idéia de um contexto limitado ( http://martinfowler.com/bliki/BoundedContext.html ), mas na verdade não esclarece a questão.

No final do dia, o que é um contexto limitado? É um agrupamento de subdomínios? O modelo e o idioma de um subdomínio? A implementação de um subdomínio? Sem essas respostas, parece bastante difícil entender como decompor um espaço de problemas da vida real em contextos limitados.

Contextos e subdomínios limitados existem em diferentes níveis.

Um subdomínio é uma parte do espaço do problema, é um particionamento natural do sistema, geralmente refletindo a estrutura da organização. Portanto, a logística e as operações podem ser separadas do faturamento e cobrança . Eric diferencia subdomínios principais , de suporte e genéricos de acordo com a relevância dos negócios no cenário fornecido.

Contextos são partes do espaço das soluções. Eles são modelos . Seria bom tê-los, refletir a partição de domínios-subdomínios ... mas a vida nem sempre é fácil. E você pode ter um domínio legado inchado que abrange tudo, ou mais contexto no mesmo subdomínio (por exemplo, aplicativo legado antigo que o aplicativo substituto que alguém está criando).

Para ter um contexto limitado, você precisa ter um modelo e um limite explícito em torno dele. Exatamente o que está faltando em muitos aplicativos orientados a dados que usam bancos de dados para compartilhar dados.

Outra maneira - ortogonal - de ver isso pode ser a seguinte. Linguagem onipresente , a condição especial em que cada termo tem uma única definição inequívoca, não é escalável. Quanto mais você o amplia, maior a ambiguidade. Se você deseja obter modelos precisos e inequívocos, precisa tornar explícitos seus limites e falar muitas pequenas línguas onipresentes, cada uma dentro de um único contexto limitado, com um objetivo bem definido. .

As técnicas de Design Orientado a Domínio são usadas para nos ajudar a criar modelos do mundo em que vivemos. Esses modelos existem como idéias nas mentes das pessoas envolvidas em um projeto.

Como a telepatia ainda está em sua infância, essas idéias são comunicadas entre as pessoas usando palavras e frases.

Palavras e frases podem ser ambíguas na melhor das hipóteses. Para nos ajudar a reduzir a ambiguidade, usamos o 'contexto' para esclarecer seu significado.

Quando as pessoas ficam profundamente imersas em um projeto de software que se estende por anos, parecem esquecer o contexto de onde surgiram as idéias que se transformaram nas palavras que se transformaram nos nomes das variáveis ​​inseridas no código.

Os iniciantes chegam ao projeto e começam a usar e consumir seu idioma. Talvez eles sejam usuários, talvez sejam desenvolvedores. Se não houver contexto fornecido a eles, eles apresentarão seu próprio contexto (e, portanto, significado) a partir de sua própria experiência de vida.

Esse novo contexto aplicado orientará como os novos desenvolvedores refatoram ou desenvolvem o código. Se eles aplicarem o contexto errado, refatorarão e desenvolverão o código, talvez levemente, na direção errada. Direções incorretas, por mais leves que sejam, podem causar problemas muito maiores na linha.

A meu ver, um "contexto limitado" é meramente um "contexto esclarecido" que é entregue aos iniciantes do projeto, para que eles não apliquem seu próprio contexto arbitrário para manchar nosso modelo lindamente aperfeiçoado.

É algum reconhecimento explícito, pela equipe, que this phrase, no this part of the projectmeio exatamente this thing(e não, como você pode muito bem pensar, that thing).

Assim como é uma boa ideia marcar os limites entre o seu jardim e o jardim do seu vizinho. Você especifica explicitamente o limite para não ficar com raiva quando eles começam a cavar um canteiro de flores em seu gramado bem cuidado.

É isso. É uma idéia muito simples, tão importante que muito foi escrito sobre isso.

Então sim. Um contexto limitado é literalmente um limite, uma "cerca", que distingue entre o contexto de um subdomínio e o contexto de outro subdomínio em um projeto.

O modelo e a linguagem de um subdomínio são isolados de outros modelos e linguagens para evitar ambiguidades no significado.

Mas sim. O mundo não é tão simples.

Você e a equipe precisam ser rigorosos ao aderir ao contexto definido. É realmente fácil ser preguiçoso e re-imaginar o contexto para cortar custos durante a construção do software.

Além disso, as coisas interagem com outras e os contextos limitados também precisam interagir. Portanto, existem vários padrões para descrever como essas interações ocorrem. Consulte o livro de Eric Evan, capítulo 14, sobre o Design Orientado a Domínio, para obter vários padrões: Kernel Compartilhado, Fornecedor do Cliente, Conformista, Camada Anticorrupção, Maneiras Separadas, Serviço de Host Aberto, Idioma Publicado.

Basicamente, o contexto limitado define alguns limites tangíveis de aplicabilidade de algum subdomínio. É uma área abstrata em que um certo subdomínio faz sentido, enquanto os outros não. Portanto, isso pode ser uma palestra, uma apresentação, um projeto de código com limites físicos definidos pelo artefato.

Em diferentes situações, uso três perspectivas diferentes, ou metáforas do conceito de contexto vinculado.

Da perspectiva do tempo de execução, ele representa limites lógicos, definidos pelo contrato de um serviço em que o modelo é implementado. O contrato pode ser representado como a API deste serviço ou um conjunto de eventos que publica e consome. Portanto, dessa perspectiva, o contexto limitado não tem nada a ver com limites físicos.

Da perspectiva de um especialista em domínio, o contexto limitado é uma área em que certos processos de negócios são implementados, a linguagem onipresente é aplicada e certos termos fazem um sentido claro, enquanto os outros não. Portanto, é apenas um retângulo desenhado em uma folha de papel ou em um quadro branco.

Para um desenvolvedor de software, ou seja, da perspectiva do código estático, um contexto limitado representa uma maneira de projetar meus modelos em torno dos subdomínios correspondentes. Com quantas bases de código um subdomínio específico é implementado? Em quais conceitos eles consistem? Quais conceitos são aplicáveis ​​em cada um deles? É por isso que se diz que contextos limitados pertencem a um espaço de solução.

Eu realmente gosto deste exemplo do conceito de contexto limitado.

Outra questão importante (se não a mais importante) é como identificar contextos limitados . Se você fizer isso de forma incorreta, você terminará com serviços faladores, inaceitáveis ​​e fortemente acoplados , também conhecidos como monólito distribuído .