Você já ouviu falar em DDD? Não, nós não estamos falando da Discagem Direta à Distância, nós estamos falando sobre o Domain-Driven Design e queremos que você saiba mais sobre essa estratégia de construção de software. Tá curioso(a)? Então vem com a gente!
Começando do começo…
O termo Domain-Driven Design foi formulado pela primeira vez no livro de mesmo título lançado pelo desenvolvedor Eric Evans, em 2003. Segundo o autor, a abordagem pode ser descrita por meio de um catálogo de padrões que visa organizar domínios de alta complexidade.
No livro o autor desenvolve um vocabulário para falar sobre essa abordagem, identificando os principais elementos conceituais que iam além das várias notações de modelagem que dominavam a discussão na época em que o livro foi lançado. No centro disso, está a ideia de que, para desenvolver software para um domínio complexo, seria preciso construir uma linguagem que incorpore a terminologia de domínio nos sistemas de software a serem construídos.
Dessa forma, o Domain-Driven Design, ou DDD, foi criado para ajudar equipes a ter mais sucesso no desenvolvimento de software com alta qualidade e complexidade. Quando implementado corretamente, o DDD entrega uma arquitetura que traduz exatamente como o domínio funciona, o sonho de qualquer negócio, não é?
Mas, afinal, o que é o Domain-Driven Design?
O DDD é uma abordagem para a modelagem de software que centraliza o desenvolvimento na criação de um modelo de domínio. Quando falamos sobre Design não estamos falando sobre do visual ou layout da aplicação, mas sim em relação ao projeto.
O Domain-Driven Design oferece ferramentas de modelagem estratégica e tática capazes de entregar um software refinado e de alta qualidade. É válido ainda ressaltar que o DDD não é uma tecnologia, framework ou uma metodologia e pode ser utilizado independente da linguagem de programação utilizada pelos desenvolvedores. No DDD modelagem e implementação andam juntas.
Implementando o DDD e desbravando alguns conceitos
O primeiro e mais essencial passo para quem quer implementar o DDD no desenvolvimento de um software será compreender o negócio. Nessa implementação existem dois papéis: o time de desenvolvimento e os Domain Experts, papel que é composto pelos profissionais especialistas no negócio ao qual o software será desenvolvido. Por exemplo, caso um time esteja desenvolvendo um software para um escritório de contabilidade, os domain experts serão contadores. Neste sentido, o domain expert atuará juntamente com o time de dev para esclarecer dúvidas, descobrir funcionalidades, regras, processos e termos que guiarão o desenvolvimento do software.
Assim, com esses dois papéis, o DDD irá entregar um código que faça sentido do ponto de vista de negócio. O resultado final deverá ser um software que os domains experts fariam se fossem os devs. Faz sentido para você?
Outro ponto importante é a aplicação de uma comunicação capaz de ser compreendida pelos especialistas do negócio e pelos desenvolvedores. É a partir desta preocupação que surgiu a Linguagem Ubíqua, que será utilizada por toda a equipe do projeto. O estabelecimento dessa linguagem globalizante é importante para não haver má compreensão entre os profissionais de T.I e os outros profissionais.
Um ponto central para a implementação do DDD será o Bounded Context, que diz respeito à delimitação do contexto. Assim, com o bounded context é possível ter mais clareza sobre os objetivos procurados, uma vez que, caso todo domínio seja colocado em um modelo, este pode se tornar complexo e rígido demais. Veja abaixo um exemplo de bounded context na prática.
Como você pode ver na imagem acima, a categoria produto aparece em dois bounded contexts diferentes. Isso significa que eles possuem papéis, características, comportamentos e responsabilidades diferentes em cada contexto.
Por fim, o Context Map será um modelo capaz de promover a visualização do software como um todo, unindo os bounded contexts e compreendendo a relação e a ligação entre essas partes. Ele é a visão global do software e cada Bounded Context dentro do mapa revela como se comunica com os demais. O mapa, portanto, deve desenhar o presente, não o futuro e é atualizado ao passo que o projeto progride.
Algumas considerações finais
Nesse post você entendeu que o DDD vai muito além do código, ele faz parte de uma jornada de aprendizado contínuo em que, durante o caminho, se é construído um projeto. Esperamos também, que você entenda a importância de se compreender um negócio para o desenvolvimento do software. A consequência natural desse trajeto é a entrega de softwares melhores, mais inventivos e de qualidade.
Faz sentido para você? Compartilhe no LinkedIn 🙂
0 comentários