Recursos especiais neste artigo:
Contém nota Quickupdate, Conteúdo sobre boas práticas, Artigo no estilo Mentoring
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."
[...] continue lendo...
Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo