Recentemente demos uma visão geral sobre o DDD no artigo Domain Driven Design estratégico, sem aprofundamentos ligados a implantação. Isso porque entendemos que a prática do DDD pressupõe o uso adequado dos conceitos ligados a estratégia. O artigo Desvendando o Context Map ainda estará posicionando na estratégia mas com o objetivo de esclarecer a relação entre os domínios e seus contextos.

O Domain Driven Design é uma abordagem completa para lidar com softwares grandes que tem como premissa o devido entendimento da complexidade do negócio utilizando a chamada Linguagem ubíqua. A partir daí se constrói mapas com domínios e sub-domínios. E continuando, a partir do mapa de domínios é possível extrair estruturas menores chamadas de contexto. O artigo Domain Driven Design: Desvendando o Context Map trará detalhes sobre os elementos dessas estruturas.

Domínios e subdomínios

Domínio é uma área de conhecimento específica, normalmente notável, e que dá sentido ao negócio. Ele é dividido em sub-domínios que são estruturas menores mas que ainda trazem uma visão de muito alto nível para a construção de um software. Um banco, por exemplo, é um domínio; uma farmáceutica, uma petrolífera, uma padaria, etc.

Já os sub-domínios são elementos como estoque, marketing, produtos, segurança, pagamento, etc. Negócios diferentes terão sub-domínos muito particulares que precisam ser entendidos de maneira isolada (até certo ponto).

Subdomínios genéricos

Os subdomínios genéricos (Generic Subdomain) são aqueles que podem estar presentes em negócios muito distintos, como marketing, Recursos Humanos, etc. Mas é claro que se o negócio da empresa for Marketing ou Recursos Humanos não tratar-se-ia de algo genérico.

Vale esclarecer que um sobdomínio genérico é um grande candidato a uma terceirização através da aquisição de um produto de prateleira (COTS, Commercial off-the-shelf), uma vez que eles não precisam trazer diferencial competitivo para o negócio.

Subdomínios Core

Ao contrário dos genéricos os subdomínios core (Core Subdomain) são aqueles que representam o negócio em essencia. São aqueles que se não existirem não há a empresa. Imagine, por exemplo, a Netflix pode ter um domínio chamado Filmes; ou uma seguradora com um domínio chamado Apólice.

Além disso, de maneira geral, esses não devem ser produtos prontos de prateleira. Empresas que fazem terceirização dessas estruturas se contentam em oferecer o mínimo para seus clientes e aceitam a ideia de que não terão isso como diferencial competitivo. Como se trata do núcleo do negócio, não te-lo como diferencial carrega riscos de não ser capaz de suportar movimentações repentinas do mercado.

Subdomínios de Suporte

Por fim, há os sub-domínios de suporte (Support subdomain) que são aqueles que amparam os subdomínios core. Imagine, por exemplo, um banco que possue um subdomínio Clientes (Core) que precisa de um subdomínio Benefícios (Support).

Limites entre os domínios

Vale destacar que o limite entre um sub-domínio e outro nem sempre é algo completamente claro. Nesses casos será possível encontrar interseções por se tratar de estruturas comuns.

Mas além disso é fundamental entender que pode existir, por exemplo, um Colaborador que pertente ao sub-domínio RH com informações de salário, férias, etc. Por outro lado, em um sub-domínio TI ele possui dados de usuário, última vez que logou, e-mail, etc. Em domínios diferentes o Colaborador terá estruturas bem diferentes que responderão às intensões específicas de cada um deles.

Contextos

Após o mapeamento dos domínios há de se fazer o mapeamento dos contextos. Esses são conjuntos de intenções, características, regras, relações, comportamentos, eventos, etc. que se interrelacionam. Os domínios do DDD são grandezas maiores enquanto os contextos são mais especializados.

Veja a seguir um diagrama abstrato que exibe um conjunto de diferentes domínios, ordenados alfabeticamente de A a M. Alguns desses domínios possuem pontos de intereseção e outros não.

Seguindo é possível ver um outro diagrama, bem parecido com o primeiro, mas representando contextos (bounded contexts) em um mapa disperso. Nesse momento ainda, propositadamente, não apresento a forma de relação entre eles. Bom, os contextos estão ordenados de 1 a 21.

Para fechar esse conceito veja um diagrama que sobrepoe os contextos aos domínios. Não é algo absolutamente bonito mas esclarece que um só domínio pode ter nele diversos contextos: veja o caso do domínio A com os contextos 1 e 2. Ao mesmo tempo há situações em que um contexto sozinho participa de mais do que um domínio, veja o exemplo do contexto 21 que participa dos domínios M e K.

Exemplificando

Como exemplo, veja um domínio hipotético de um banco e alguns potenciais contextos

1. Gerenciamento de Contas: esse contexto pode envolver a abertura, o fechamento, o gerenciamento e a atualização de contas bancárias para clientes.
2. Cartões de Crédito: esse contexto pode envolver o gerenciamento de cartões de crédito emitidos para os clientes, incluindo a solicitação, o cancelamento e a gestão de limites de crédito.
3. Investimentos: esse contexto pode envolver a oferta de serviços de investimento para os clientes, incluindo a abertura de contas de investimento, a transferência de fundos e a gestão de portfólios.
4. Empréstimos: esse contexto pode envolver a oferta de empréstimos para os clientes, incluindo a solicitação, a aprovação e a gestão de pagamentos.
5. Serviços Bancários On-line: esse contexto pode envolver a oferta de serviços bancários on-line para os clientes, incluindo acesso às contas, transferências eletrônicas e pagamentos de faturas.

Veja também: 7 APIs públicas, gratuitas e de qualidade.

Tipos de relação entre os contextos

Agora que entendemos os domínios, os contextos e como eles se posicionam, temos agora a necessidade de saber relacioná-los. Entenda que um contexto pode ter relação com outro. Desvendando o Context Map: Vale destacar que em algumas empresas um contexto define uma de suas áreas ou squads. Portanto vamos falar sobre quais são as possíveis relações entre esses diferentes times e depois os padrões gerais de relação entre eles.

Relacionamento entre os times

1 – Mutually Dependent

Nesse caso há uma relação de dependência mútua. Duas equipes ou bounded contexts são mutuamente dependentes: seus artefatos ou sistemas de software precisam ser entregues juntos para serem bem-sucedidos e funcionarem. Muitas vezes, você verá um vínculo próximo e recíproco entre dados, funcionalidades e recursos dessas equipes. Essas equipes também precisam de muita comunicação entre si para coordenar seus esforços.

2 – Upstream Downstream

As ações de uma equipe upstream afetarão a equipe downstream, mas as ações downstream não têm um impacto significativo na equipe upstream.

3 – Free

Um Bounded Context ou uma equipe que nele trabalha é livre e as mudanças em outros Bounded Contexts não influenciarem seu sucesso ou fracasso. Não existe, portanto, nenhum tipo de vínculo organizacional ou técnico entre essas equipes.

Context Map Patterns

A relação entre os contextos, do ponto de vista estratégico, tem características particulares. Há o elenco de um conjunto com nove padrões de referência que serão explicados a seguir.

1 – Open-host Service

Esse contexto funciona como um protocolo de referência que outros contextos possam fazer uso. A equipe que fornece um serviço de host aberto geralmente está em uma posição upstream, enquanto os clientes que o usam são equipes downstream. Os contextos que consomem desse são livres para serem conformistas ou para construir camadas anticorrupção.

2 – Conformist

Nesse cenário o upstream define a linguagem e as características necessárias e o downstream precisa se adaptar de maneira servil a todas as mudanças. Não cabe ao downstream fazer nenhum tipo de ponderação. Um exemplo claro desse padrão é quando há uma nova regulação e o sistema de um banco, por exemplo, precisa se adaptar a ele.

3 – Anticorruption Layer

Esse contexto é uma camada de isolamento entre o upstream e os contextos que dele consomem. Nesse caso a Camada Anti-corrupção abstrai as mudanças que ocorrem no upstream de modo que se houver mudança repentina os downstreams não sejam diretamente afetados (ou reduza o risco).

4 – Shared Kernel

O núcleo compartilhado deve ser combinado pelas duas equipes. Ele deve ser o menor possível e nenhuma mudança pode ser feita nesse núcleo sem contatar ambas as equipes.

5 – Partnership

Quando uma falha em um desenvolvimento afeta ambos os contextos deve-se ter uma relação de parceria para não impactar um ao outro. Há de se fazer uma coordenação inteligente para que a integração contínua funcione de maneira a compreender os dois contextos e não gerar impactos.

6 – Customer / Supplier Development

Nesse caso há uma relação upstream downstream comum, onde as alterações do downstream não afetam o upstream. Porém, nesse caso a equipe upstream faz um planejamento de modo a não afetar, reduzir o impacto ou sincronizar as modificações com o downstream.

Entenda nesse caso que se o upstream fizer alterações, ele pode considerar, por exemplo, um planejamento claro de versões e retrocompatibilidade para que o downstream não fique prejudicado. Em situações específicas as alterações são combinadas entre as partes.

7 – Published Language

Há situações onde o modelo de comunicação aplicado por um contexto precisa ser estruturado para que demais contextos consumam com uma linguagem comum. Um exemplo disso é o uso de cartões de visita vCard ou itens de calendário com iCalendar. Normalmente esse padrão se combina com o padrão open-host service.

8 – Separate Ways

Esse padrão é uma garantia de que dois contextos não terão relação e devem existir de modo completamente independente, cada um com suas regras.

9 – Big Ball Of Mud

Esse é o cenário onde todos os contextos são misturados, não há delimitaçõe de domínios. Do ponto de vista da programação há várias classes anêmicas, outras com todas as regras, e coisas do tipo.

Desvendando o Context Map: Conclusão

O domain driven design é um modelo organizado para a tradução das necessidades de negócios em estruturas que se tornarão sistemas. Isso significa que DDD não é arquitetura em si, uma vez que diferentes contextos podem seguir diferentes arquiteturas. Ou ainda mais, há situações em que não faz sentido utilizar DDD e, portanto, a arquitetura utilizada será outra. Significa também que DDD não é codificação em si, embora seja possível utilizar padrões de codificação que não foram abordados nesse artigo.

O artigo Desvendando o Context Map focou em deixar esses pontos claros e mostar os padrões utilizados e definidos para modelos de contexto com Domain Driven Design. Outros detalhes podem ser encontrados em Context Mapping.