.NET - Conceitos DDD para iniciantes

Vou iniciar citando um trecho do livro de Vaugh Vernon que diz : "Entrar em contato com o DDD pode ser como um voo para uma criança. A vista área é impressionante, mas às vezes as coisas parecem tão desconhecidas que impedem que saíbamos exatamente onde estamos..."

Assim, para quem esta iniciando a melhor coisa a fazer é dar um passo de cada vez, e, para isso, hoje eu vou apresentar alguns conceitos básicos importantes usados no Domain Driven Design.

Logo de início já vou destacar que o DDD não é arquitetura, não é tecnologia, não é framework e não é linguagem.

O DDD (Domain Driven Design) é uma abordagem ao design de software que se baseia no conceito de domínio.

Mas o que significa domínio ?

"Um domínio é um campo de estudo que define um conjunto de requisitos, terminologia e funcionalidade comuns." - Wikipedia

Se o seu negócio é vender cachorro quente o seu domínio vai envolver todo o processo envolvido nesta venda e pode ter mais de um domínio como lanches, produtos, clientes, vendas etc.

Assim, o DDD visa facilitar a criação de aplicativos complexos, conectando as partes relacionadas do software em um modelo focado no negócio que esta em constante evolução.

Um Bounded Context é um limite conceitual no qual um modelo de domíno é aplicável, sendo que ele fornece um contexto para a linguagem ubíqua que é falada pela equipe e é expressa no modelo de software projetado.

Dessa forma, a linguagem ubíqua define que a configuração na qual uma palavra ou declaração aparece é que determina o seu significado.

Quando trabalhamos em um projeto de software relativamente grande, muitos modelos estão em jogo. Se não administrarmos com cuidado, as equipes que trabalham de forma independente poderão resolver problemas semelhantes de maneiras diferentes e isso poderá levar a códigos mais difíceis de entender ou pouco confiáveis.

Portanto, devemos definir explicitamente o contexto no qual o modelo se aplica definindo limites e manifestações físicas, como diferentes esquemas de banco de dados ou bases de código.

Para o modelo de domínio envolvido na venda de cachorro quente podemos ter um contexto delimitado para o modelo de domínio Clientes e outro para Lanches:

Model (Modelo)

O modelo de um projeto orientado a domínio é a sua solução para o problema. O Model geralmente representa um aspecto da realidade ou algo de interesse do negócio : o lanche, o cliente, a entrega, etc.

O Model também costuma ser uma simplificação da imagem maior e, portanto, os aspectos importantes da solução são concentrados enquanto todo o resto é ignorado.

Podemos pensar no Model como um sistema de abstrações que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas relacionados a esse domínio. Se o design não for mapeado para o modelo de domínio, esse modelo terá pouco valor e a correção do software será suspeita.

Para a venda de cachorro quente podemos ter as classes : Lanche, Cliente, etc.

Ubiquitous Language (Linguagem Onipresente)

A ubiquitous language é uma linguagem estruturada em torno do modelo de domínio e usada por todos os membros da equipe para conectar todas as atividades da equipe ao software.

A comunicação é muito importante em uma equipe e devemos garantir que uma definição clara de termos específicos esteja disponível para todos.

A comunicação diária está desconectada dos termos usados no código e isso pode levar a mal-entendidos. Para uniformizar a comunicação termos técnicos são substituídos por termos que o usuário entenda.

A sua adoção faz com que a equipe se comprometa a exercer uma linguagem uniforme em todas as comunicações e no código, e resolve a confusão sobre os termos da conversa.

A linguagem ubíqua é aplicável dentro de um único Contexto Delimitado. Assim para o contexto delimitado Clientes podemos ter a definição dos termos usados como: Cliente, Pessoa, Local de Entrega, Endereco etc.

Uma vez que um contexto delimitado tenha sido definido, devemos manter o sincronismo e o equilíbrio.

Quando várias pessoas trabalham no mesmo código, é difícil manter tudo coerente e funcionando. É fácil alterar ou interromper um comportamento existente de uma parte do software como efeito colateral de um desenvolvimento de recurso ou correção de bug.

Temos que criar e trabalhar com um processo que mescla frequentemente todo o código, executa testes automatizados para verificar problemas o mais rápido possível.

O termo “integração contínua” é usado hoje em dia principalmente no contexto do DevOps, que significa mesclar, criar e testar o código continuamente.

Ao usar o DDD, também discutimos o domínio e a linguagem onipresente regularmente. A interação frequente entre os membros da equipe garante que todos os códigos sejam escritos em sincronia com o modelo e que nenhum sub-contexto surja acidentalmente com um idioma separado.

Assim podemos definir um fluxo básico no qual o processo de implementação do DDD pode ser aplicado:

"E este evangelho do reino será pregado em todo o mundo, em testemunho a todas as nações, e então virá o fim."
Mateus 24:14