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

38

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

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

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

Martin Fowler discute brevemente a ideia de um contexto delimitado ( link ), mas realmente 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 do problema da vida real em contextos limitados.

    
por Michael 30.04.2014 / 18:53
fonte

3 respostas

36

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, refletindo frequentemente a estrutura da organização. Assim, logística e operações podem ser separadas de faturamento & faturamento . Eric diferencia os core , suporte e subdomínios genéricos de acordo com a relevância dos negócios no cenário dado.

Contextos são partes do espaço de soluções. Eles são modelos . Seria bom tê-los, refletir o particionamento de domínios-subdomínios ... mas a vida nem sempre é assim tão fácil. E você pode ter um domínio herdado inchado abrangendo tudo, ou mais o contexto no mesmo subdomínio (ou seja, o aplicativo legado antigo que o aplicativo substituto 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 baseados em dados que usam bancos de dados para compartilhar dados.

Outro modo - ortogonal - de ver pode ser o seguinte. Linguagem ubíqua , a condição especial em que cada termo tem uma única definição não ambígua não é escalável. Quanto mais você ampliá-lo, mais ambigüidade se instala. Se você quer alcançar modelos precisos e não ambíguos, você precisa deixar seus limites explícitos, e falar muitos pequenos idiomas ubíquos, cada um dentro de um único contexto limitado, com um propósito bem definido. .

    
por 05.05.2014 / 19:39
fonte
7

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

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

Palavras e frases podem ser ambíguas nos melhores momentos. Para nos ajudar a reduzir a ambigüidade, usamos o "contexto" para esclarecer seu significado.

Quando as pessoas ficam profundamente imersas em um projeto de software que abrange anos, elas parecem esquecer o contexto do qual vieram as ideias que se transformaram nas palavras que se transformaram nos nomes das variáveis que foram incorporadas ao código.

Iniciantes chegam ao projeto e começam a usar e consumir sua linguagem. 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, o significado) de sua própria experiência de vida.

Esse contexto recém-aplicado orientará como os novos desenvolvedores refatoram ou desenvolvem o código. Se aplicarem o contexto errado, eles refatorarão e desenvolverão o código, talvez sempre ligeiramente, na direção errada. Direcções erradas, por mais ligeiras que sejam, podem causar problemas muito maiores no futuro.

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

É um reconhecimento explícito, por parte da equipe, que this phrase , em this part of the project significa exatamente this thing (e não, como você pode pensar, that thing ).

Assim como é uma boa idéia marcar os limites entre o seu jardim e o jardim do vizinho. Você especifica o limite explicitamente para que você não fique irritado quando eles começarem a cavar um canteiro de flores no seu gramado perfeitamente cuidado.

É isso. É uma ideia muito simples, tão importante que muita coisa foi escrita sobre isso.

Então sim. Um contexto limitado é literalmente um limite, uma 'cerca', que distingue entre o contexto de um subdomínio do 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 ambigüidades 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 coisas e os contextos limitados também precisam interagir uns com os outros. Portanto, existem vários padrões para descrever como essas interações ocorrem. Veja o livro de Eric Evan, Domain Driven Design, Capítulo 14 para estes vários padrões: Kernel Compartilhado, Fornecedor do Cliente, Conformista, Camada de Anticorrupção, Formas Separadas, Serviço de Host Aberto, Linguagem Publicada.

    
por 30.04.2014 / 23:25
fonte
0

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

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

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

Na perspectiva de um especialista em domínio, o contexto limitado é uma área em que determinados processos de negócios são implementados, a linguagem onipresente é aplicada e alguns termos fazem um sentido claro, enquanto os outros não. Então, é apenas um retângulo desenhado em uma folha de papel ou 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 de subdomínios correspondentes. 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 os contextos limitados pertencem a um espaço de solução.

Eu realmente gosto este exemplo do Conceito de Contexto Limitado.

Outra questão importante (se não a mais importante) é como identificar contextos limitados . Se você fizer isso incorretamente, você terminará com conversível, inamovível e serviços strongmente acoplados , também conhecidos como monolito distribuído .

    
por 06.10.2017 / 14:17
fonte