Na série de recortes de trechos de trabalhos acadêmicos que fiz no passado sobre DDD (Domain-Driven Design)... aqui vai a parte 3 contendo trechos do capítulo 4 de meus resumos sobre DDD.

>

4.3 Contexto Delimitado

O Contexto Delimitado constitui uma fronteira lógica e explícita entre os diferentes conceitos, propriedades e operações que formam o Modelo de um Domínio (Vernon, 2013). Isso se deve ao fato de utilizar a Linguagem Ubíqua para definir as classes (OOP) e demais objetos que constituem o modelo. Assim, os termos e expressões do negócio que fazem sentido apenas dentro de um determinado contexto são mantidos juntos, formando uma fronteira linguística que evita ambiguidades relacionadas a palavras similares em contextos diferentes (Vernon, 2013).

Idealmente, deve-se projetar o Contexto Delimitado de forma a estar contido em apenas um Subdomínio com o intuito de segregar o Modelo do Domínio em áreas distintas do negócio conforme seus objetivos (Vernon, 2013).

Segundo Evans (2011), para manter os conceitos e termos do modelo consistentes com o Contexto Delimitado ao qual pertence é necessário aplicar a Integração Contínua.

A Integração Contínua é o processo de consolidar os códigos-fontes e demais artefatos de implementação utilizados no modelo. Quando este processo é acompanhado de testes automatizados fica mais rápido detectar fragmentações no modelo (Evans, 2011).

Fragmentações do modelo é uma tendência comum quando diversas pessoas trabalham em um mesmo modelo (Evans, 2011).

Por isso, é importante manter o Contexto Delimitado coeso. Ou seja, apenas os Especialistas do Domínio, Arquitetos e Desenvolvedores envolvidos em um determinado Contexto Delimitado entendem seu vocabulário com exatidão suficiente para traduzi-lo para outro contexto delimitado numa integração, caso necessário, ou explicá-lo para as demais partes interessadas (stakeholders) do sistema (Vernon, 2013).

Os outros blocos básicos do DDD que pertencem à modelagem tática, tais como Módulos, Agregados, Eventos e Serviços, por exemplo, também são modelados e construídos de acordo com as fronteiras estabelecidas pelo Contexto Delimitado e este possuirá o tamanho necessário para comportar as necessidades do negócio de acordo com a Linguagem Ubíqua corrente (Vernon, 2013). O conjunto de um ou mais Contextos Delimitados formam um conjunto de modelos de software (dentre estes, o Modelo do Domínio) que constituem o espaço da solução (space solution) (Vernon, 2013).

A decomposição de um problema do Domínio em áreas ou sub-áreas distintas ou relacionadas ajudam a elaborar um Modelo de Software consistente no que tange à melhora de nossa capacidade de abstração e formação de um modelo ou mapa mental (mindset) que possa guiar na construção de uma solução eficaz e eficiente para o problema proposto, identificando corretamente os elementos envolvidos no Sistema como um todo (Meyer, 1988 apud Pressman, 2001 p. 373).

Sendo assim, o Contexto Delimitado se torna a ponte entre o Modelo Conceitual do Domínio e o software que está, efetivamente, sendo construído. Ou seja, é dentro dos limites do Contexto Delimitado que os aspectos técnicos e não-técnicos (de negócio) são modelados e construídos com a ajuda dos padrões estratégicos e táticos do DDD, respectivamente, para formar o software funcional. É a parte concreta, a realização da visão estratégica (Vernon, 2013).

Antes de detalhar os elementos que constituem o Contexto Delimitado (fisicamente falando), é necessário discutir os aspectos básicos da Integração entre diferentes Contextos Delimitados para que se possa determinar a Arquitetura de Software apropriada e descobrir como realizar a modelagem do Projeto com base no comportamento e relação entre as diferentes equipes ou áreas que, frequentemente, participam de um mesmo Projeto de Software visto que, dificilmente, um contexto delimitado está isolado em si mesmo (Vernon, 2013).

...mais sobre Integração entre Contextos Delimitados no próximo artigo, parte 4.

Referências

Vernon, 2013: Vernon, Vaughn , Implementing Domain-Driven Design, 2013

Evans, 2011: Evans, Eric, Domain-Driven Desgin Reference, 2011

Meyer, 1988 apud Pressman, 2001 p. 373: Meyer, B.; Pressman, Roger S, Object-Oriented Software Construction; Software engineering: a practitioner’s approach, 2001