DDD - Domain-Driven Design com .NET

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (4)  (0)

Conheça nesse artigo o Domain Driven Design, ou simplesmente DDD. Uma nova metodologia de design que está presente em várias aplicações desenvolvidas em .NET

Atenção: esse artigo tem uma palestra complementar. Clique e assista!

[lead]Do que se trata o artigo

O Domain-Driven Design é a reunião de um conjunto de princípios e práticas que surgiu com o intuito de atenuar problemas que atormentam desenvolvedores há algum tempo. Não se trata de nenhum novo conceito, mas sim uma espécie de “guia” para a aplicação de práticas já existentes de forma a melhorar o processo de desenvolvimento.

Para que serve

Através de diversos princípios e padrões de projeto, o Domain-Driven Design visa ajudar equipes de desenvolvimento a entender melhor o contexto dos projetos, permitindo assim utilizar esse conhecimento para gerar um produto final com mais qualidade e satisfação ao cliente.

Em que situação o tema é útil

O Domain-Driven Design apresenta um conjunto de valores e práticas que têm como objetivo auxiliar desenvolvedores a despender mais tempo no que realmente importa, que é o domínio de uma aplicação. Quanto mais complexo o domínio, mais retorno a aplicação do DDD trará.

Resumo do DevMan

Muito provavelmente você já viu a sigla DDD estampada em algum site ou blog de tecnologia ultimamente. Este artigo tem como objetivo dar um embasamento sobre o Domain-Driven Design, tão comentado atualmente. O principal objetivo é mostrar as ideias e princípios básicos, mostrando pequenos trechos de código de alguns padrões para exemplificar a implementação dessas ideias no código de nossas aplicações.[/lead]

Para quem nunca ouviu 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 disciplina ou 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.

O termo Domain-Driven Design foi criado por Eric Evans em seu livro entitulado “Domain-Driven Design: Tackling Complexity in the Heart of Software”, onde ele fala extensivamente sobre esses princípios e como eles podem ser aplicados e suportados em código, mostrando diversos padrões de projeto de forma detalhada e suas ideias para um melhor desenvolvimento de software após duas décadas percebendo os mesmos problemas.

[subtitulo]Mas afinal, o que é DDD?[/subtitulo]

A principal ideia do DDD é a de 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 que o mesmo se propõe a resolver, ou em outras palavras, a regra de negócio. Ela é a razão do software existir, por isso deve receber o máximo de tempo e atenção possíveis. Em praticamente todos os projetos de software, a complexidade não está localizada nos aspectos técnicos, mas sim no negócio, na atividade que é exercida pelo cliente ou problema que o mesmo possui. Como já diz o título do livro de Eric Evans, esse é o “coração”, o ponto central de qualquer aplicação, portanto todo o resto deve ser trabalhado de forma que este “coração” seja entendido e concebido da melhor forma possível.

Vamos utilizar um exemplo para tentar clarificar essa ideia: imagine que o mais novo cliente de sua empresa é um call center e você precisa desenvolver um software que controle todos os processos do mesmo. Mas quem conhece os processos de um call center? Seu gerente? Os desenvolvedores? Com certeza não. Todos estes provavelmente já foram atendidos por um, talvez tenham ideias vagas sobre o funcionamento, mas ninguém possui conhecimento suficiente para guiar o desenvolvimento desse projeto. Quem realmente conhece o negócio são os atendentes, supervisores e demais funcionários desse call center. É deles que esse conhecimento deve ser extraído, de maneira que a equipe do projeto possa se alinhar com seus desejos e expectativas.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?