Bounded Context – Context Map

Nos últimos posts, eu falei um pouco sobre o que é um bounded context e as vantagens que temos quanto começamos a utilizar essa abordagem.
Acredito eu que, com o conhecimentos que adquirimos até agora, é possível ver de uma forma clara o poder dessa abordagem e as vantagens que ganhamos ao utilizá-la.
Vamos aprender agora como podemos ter uma visão de alto nível dos nossos bounded contexts e como podemos integrá-los.

O que é ?

Context map é um artefato de suma importância que irá nos auxiliar a capturar a realidade que vamos enfrentar, isto é, garante que o time tenha uma visão holista do sistema. Ele nos ajuda a garantir que os limites entre os contextos de um sistema estejam definidos explicitamente e que o time tenha o conhecimento de quais são os pontos de integração entre eles.

figura 1.0

ContextMap

A figura 1.0 é um exemplo de um context map, Vamos agora entender cada elemento dentro dele.

Analisando o Context Map

Direção do relacionamento

Quando definimos através das linhas qual BC se relaciona com qual, precisamos definir qual contexto que depende de uma informação que o outro fornece. O DDD utiliza-se do termo upstream e downstream para deixar essa informação explicita. Podemos dizer que um contexto upstream influencia um contexto downstream, ou seja,  o contexto downstream depende das informações que o upstream fornece (para se ter uma ideia, isso, em nível de aplicação, pode ser representado como qual class library possui a referência de outra dll)

Integridade do contexto

Às vezes, precisamos de informações de um contexto que faz parte de algum legado, de uma informação de terceiro ou de um ERP. Para esse tipo de integração, precisamos garantir que o nosso contexto possua uma proteção contra mudanças que possam vir do contexto upstream. Para tal, o DDD nos fornece um pattern chamado Anti-Corruption Layer (ACL). Para deixar claro no nosso context map que um contexto downstream necessita de uma ACL( para que não sofra nenhuma mudança que não seja motivada pelo domínio do negocio e sim pelos dados),utilizamos a sigla ACL como na  figura 1.0.

Relacionamento entre times

Muitas vezes, temos vários times trabalhando em conjunto para atender uma determinada necessidade e nem sempre a comunicação entre esses times é possível ou fácil de ser feita, No context map, também deixamos isso explicito.

Imagine que o time que você faz parte está trabalhando em um contexto  que possui um outro contexto como upstream,  no qual  é um time de terceiro que trabalha e não existe a possibilidade de entrar em contato com o mesmo. Neste exemplo não é possível uma  interação ou negociação de qualquer coisa relacionado a essa  situação e, neste caso, precisamos ser conformistas com a realidade que temos. Esse cenário de interação (isto é, nenhum) com o outro time pode ser representada de forma explicita utilizando o termo conformist

Em contra partida, se dois times estão trabalhando em direção a um objetivo em comum, esses times possuem uma parceira, garantindo que exista uma cooperação para que a integração entre os dois contextos seja realizada. Para representar esse tipo de relacionamento no context map claramente, utilizamos o termo partnership

Quando o contexto downstream possui confiança nas informações que o contexto upstream fornece(não o contrário, isto é, o upstream não possui confiança no downstream) temos um relacionamento de cliente-fornecedor que  chamamos de customer-supplier.

 

 

Conclusão

Acabamos de ver como podemos mapear quais BCs se comunicam entre si, os tipos de relacionamento entre os BCs, os tipos possíveis de interação entre os times (quando se trabalha com mais de um) e como garantir a integridade de um BC entre as comunicações.

Repare que, utilizando este tipo de artefato, conseguimos ter uma ótima visão do trabalho que teremos e de como cada parte se conversa. A partir do context map, já conseguimos pensar  nas formas possíveis de integração entre eles e qual o nível de esforço que cada time e BC precisará ter.

Comentei no meu ultimo post que o próximo(no caso este) seria o último e que veríamos, na prática,como integrar dois(ou mais) contextos, porém não poderia dar continuidade sem falar um pouco sobre context map, já que é um artefato muito útil de se ter em mãos 🙂

 

Referencias

Patterns, Principles, and Practices of Domain-Driven Design

DDD with Context Map

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s