Artigos Delphi Melhore seu Código com Domain Driven Design
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Contém nota Quickupdate, Conteúdo sobre boas práticas, Artigo no estilo Mentoring
Cenário
Durante o ciclo de vida de um projeto, várias alterações de regras de negócio acontecem. Muitas vezes é preciso responder a essas mudanças de forma muito rápida e, sem pensar, acabamos codificando algo que resolve o problema na hora, mas que na verdade, não foi o melhor código. Com a correria do dia não voltamos a rever esse trecho do sistema e o deixamos lá. Esse é um cenário comum para pesquisas SQL. Para resolver um problema rapidamente, escrevemos uma sentença que já existe em algum lugar do sistema, ou seja, replicamos essas instruções e esquecemos de corrigir isso. Com o tempo só vamos lembrar dessa sentença quando a mesma precisar ser alterada, então teremos que procurar por todo o sistema. O pior é que isso irá aumentar sempre, até que uma simples correção de alguma pesquisa SQL se torne um desafio a ser corrigido em vários locais. Com regra de negócio espalhada por vários locais, fica difícil o entendimento do sistema por outro desenvolvedor e até mesmo pelo próprio criador do projeto. Com DDD podemos organizar nosso código, mesmo procedural, de forma elegante, pensando nas regras de negócio e não em tecnologia.


Em que situação o tema é útil
Na organização do código, aplicando boas práticas que resultarão em facilidade de entendimento e manutenção

Existem alguns termos que passam despercebidos pela maioria da comunidade Delphi, uma vez que a ferramenta favorece um estilo de programação RAD, onde se desenvolve muito rápido e quase sempre, a arquitetura não é abordada como deveria. Por isso, muitos nunca ouviram falar sobre Domain-Driven Design, é importante ressaltar que não se trata de um novo framework nem uma nova linguagem de programação, mas sim de uma nova abordagem (alguns diriam até um novo paradigma) para o desenvolvimento de software, ou seja, uma série de ideias e princípios que ao serem aplicados no processo de desenvolvimento de software podem simplificar o mesmo e agregar mais valor ao produto final.

História

O Domain-Driven Design foi criado por Eric Evans e retratado em seu livro “Domain-Driven Design: Tackling Complexity in the Heart of Software”, onde ele fala extensivamente sobre os princípios que envolvem a ideia do DDD e como eles podem ser aplicados e suportados em código, mostrando de forma detalhada a solução para problemas que ocorrem a mais de vinte anos.

O que é importante?

O DDD diz que o mais importante em um software não é o seu código, nem sua arquitetura, nem a tecnologia sobre a qual foi desenvolvido, mas sim o problema a ser resolvido, ou seja, a regra de negócio. Se pararmos para pensar isso realmente faz sentido, pois sem ela não existe razão do software existir. É por isso que devemos focar nosso tempo e atenção nessa regra, mais do que em qualquer outra coisa. A complexidade de um sistema, em quase 100% dos projetos não está na tecnologia utilizada mas no negócio envolvido. Esse negócio é chamado de “coração” pelo livro do Eric Evans, é o centro do aplicativo e todo o restante deve ser construído para atender esse centro da melhor forma possível.

Para deixar esse ideia bem clara, vamos imaginar um sistema de caixa de supermercado que você foi incumbido de desenvolver. Com quem você irá tirar suas dúvidas sobre o processo de funcionamento? O dono da rede? Os clientes que compram no supermercado? Eles podem ter uma noção de funcionamento, mas, quem conhece a fundo, é quem está envolvido diretamente com as rotinas de caixa, ou seja, os caixas desse supermercado. Agora vamos fazer uma análise do negócio à luz do DDD.

...
Quer ler esse conteúdo completo? Tenha acesso completo