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

>

4.4 Mapa de Contexto

O Mapa de Contexto faz parte da Modelagem Estratégica do DDD, porém com foco na avaliação das possíveis integrações existentes entre diferentes Contextos Delimitados presentes na solução de software (solution space assessment) (Vernon, 2013).

O objetivo é esclarecer a situação atual do projeto em relação às partes distintas do software que compõe a solução como um todo, no que diz respeito às suas integrações. Assim, é possível analisar as diferentes estratégias de integração que podem ser aplicadas no cenário atual e futuro, além de facilitar a comunicação entre as diferentes equipes que porventura participem ou influenciam direta ou indiretamente no Projeto de Software.

Quando um Contexto Delimitado exerce influência sobre o outro através do fornecimento de algum serviço ou informação este é conhecido como Upstream.

E demais Contextos Delimitados que o consomem é chamado de Downstream.

O Mapa de Contexto poderá ser refinado e detalhado conforme evolução do modelo e as necessidades do negócio, do projeto e das equipes envolvidas em cada Contexto Delimitado. O código-fonte empregado na implementação das integrações entre estes modelos (os contextos delimitados) expressam o nível máximo de detalhamento esperado (Vernon, 2013).

4.5 Integração entre Contextos Delimitados

As possíveis relações de integração entre diferentes Contextos Delimitados e relações entre as Equipes de Projeto podem ser tratadas de diferentes formas no DDD. Para isto, são fornecidos um conjunto de padrões para organização e integração entre Contextos Delimitados que totalizam nove estratégias distintas (Evans, 2003 apud Vernon, 2013 p. 92), definidas a seguir:

• Partnership – dois times ou equipes diferentes resolvem colaborar para o desenvolvimento de interfaces comuns (contratos) que beneficiam ambos os sistemas ou contextos delimitados envolvidos. Assim, as funcionalidades inter-dependentes que são desenvolvidas e oferecidas por diferentes contextos delimitados podem ser planejadas e implantadas num mesmo ciclo do software (release).
• Shared Kernel – Partes de um modelo e seu código-fonte associado que pode representar um interesse ou dependência em comum entre dois ou mais subdomínios podem ser compartilhados por equipes diferentes. Evita-se a duplicação desnecessária de código e mantém-se um núcleo compartilhado comum que é atualizado mediante concordância de todos os envolvidos e que funciona dentro de um processo de integração contínua.
• Customer-Supplier – Quando dois ou mais contextos delimitados possuem uma relação do tipo Upstream e Downstream, as equipes envolvidas podem cooperar de maneira que o sucesso da equipe do lado Upstream depende do sucesso da equipe do lado Downstream e vice-versa, ou seja, são interdependentes. Por isso, os requisitos priorizados e demandados do lado Downstream implicam no planejamento do lado Upstream.
• Conformist – Quando uma equipe que cuida de um Contexto Delimitado do lado Upstream não possui obrigatoriedade de fornecer serviços (ou API's) adaptados às necessidades das equipes do lado Downstream, estas são levadas a aderir ao seu modelo a fim de evitar complexidades de tradução entre os modelos no lado Downstream.
• Anticorruption Layer – Nos casos nos quais o modelo de um Contexto Delimitado do lado Downstream não deva sofrer influências diretas de outros modelos do lado Upstream, pode-se definir uma camada de tradução entre os modelos de forma a permitir o uso das funcionalidades oferecidas pelo Upstream preservando o modelo de domínio do Contexto Delimitado do lado Downstream,isolando-o das modificações e interfaces externas.
• Open Host Service – Provê um conjunto de serviços para determinados subsistemas de um software que podem ser acessados e estendidos conforme um protocolo compartilhado em formato aberto e coerente por diversos Contextos Delimitados.
• Published Language – Uma camada de tradução entre dois modelos diferentes irá necessitar de uma linguagem comum (técnica ou não-técnica) para expressar as informações e comportamentos existentes em cada Contexto Delimitado envolvido. Esta linguagem deverá ser documentada e compartilhada (de forma manual ou automática). Geralmente, esta mesma linguagem é usada em conjunto com o padrão Open Host Service.
• Separate Ways – Quando os benefícios de integrar-se um Contexto Delimitado específico a outros não são significantes ou justificáveis, declara-se que o Contexto Delimitado em questão deverá manter-se independente de todos os outros, tornando-o especializado e autocontido dentro de um determinado escopo.
• Big Ball of Mud – Quando se detecta que as partes de um sistema existente (legado) não possuem consistência entre fronteiras (ou mesmo não possua fronteiras definidas) e os modelos estão espalhados dentro do domínio da aplicação, aplica-se uma nova fronteira artificial para contê-lo. Assim, são adotadas práticas de modelagem simplificadas que permitam a interação com estes sistemas legados de forma a evitar a complexidade oriunda deste. Geralmente, usam-se Adaptadores (Gamma el al, 1994) para o desenvolvimento de integrações deste tipo.

A identificação das integrações que podem existir entre diferentes Contextos Delimitados auxiliam na construção de Mapas de Contexto e podem auxiliar na investigação das influências destas integrações na Arquitetura de Software (Vernon, 2013). Por exemplo, Eventos de Domínios e Notificações entre diferentes Contextos Delimitados podem ser necessários ao projeto, e o Mapa de Contexto pode ajudar a identificar se uma Arquitetura Orientada a Eventos é mais indicada para alguns Módulos do projeto de software (o conceito de Módulos será visto adiante na seção 5.6 do capítulo 5).

Esta parte conceitual sobre Mapas de Contexto serve para mostrar as diferentes estratégias de integração existentes no DDD. Ressaltando que a maior parte destas estratégias resultam em padrões de modelagem técnica, ou seja, no nível do código, que ajudam a manter as fronteiras (subdomínios e contextos delimitados) bem definidas dentro e ao redor do sistema (com a ajuda de outras técnicas de modelagem do DDD tais como Segregated Core e Responsibility Layers) (Evans, 2003).

Assim, uma vez definido quais padrões de organização e integração compõe uma solução, pode-se iniciar a avaliação dos estilos arquiteturais de software (Gorton, 2011) e possíveis tecnologias e design patterns envolvidos (Gamma el al, 1994), por exemplo:

• Open Host Service – Este padrão pode ser implementado com tecnologias baseadas em REST (Representational State Transfer) (Gorton, 2011), ou ainda uma API RPC (Remote Procedure Call) (Vernon, 2013).
• Published Language – Poderia ser definida como um conjunto de esquemas XML (XSD – XML Schema Definition) e utilizada juntamente com mensagens XML (eXtensible Markup Language). Ou ainda ser modelada como objetos JSON (Javascript Object Notation) (Vernon, 2013).
• Anticorruption Layer – Pode ser utilizado o padrão Adaptador (Gamma el al, 1994) para se implementar esta camada juntamente com XML ou JSON para padronizar as mensagens e definir um mapa de tradução (Vernon, 2013).

Concluindo este capítulo, é importante destacar que é necessário conhecer estes padrões de integração para identificar os pontos de contatos entre diferentes Contextos Delimitados e prover os aspectos conceituais e técnicos requeridos pela solução de software (Evans, 2011).

...parando por aqui...este assunto continuará no próximo artigo.

Referências

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

Evans, 2003 apud Vernon, 2013 p. 92: Evans, Eric; Vernon, Vaughn., Implementing Domain-Driven Design, 2013

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

Gamma el al, 1994: Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John., Design Patterns, 1994

Gorton, 2011: Gorton, Ian, Essential Software Architecture, 2011