«

»

May 07

Print this Post

Domain-Driven Design

Quando vamos desenvolver um software, sabemos que esse software é para atender alguma necessidade de alguém. Essa necessidade para quem solicitou o software pode ser caracterizado como um problema. Com isso concluímos que um software serve para resolver um problema. Todas as necessidades em volta do problema podemos denominar de Domínio.

Com isso, o nome Domain-Drive Design poderia ser traduzido para: Guiar o Design da Aplicação pelo Domínio ou quem sabe: Programação Orientada a Domínios(Problemas).

Esse conceito envolve muito mais informação do que códigos é um padrão mais conceitual do que prático.

O que vemos em nosso dia-a-dia, é desenvolvimento de softwares guiados a qualquer coisa, menos pelo domínio.

É familiar o desenvolvimento de um software inteiro e na hora do cliente homologar, ele pedir um monte de mudanças?

Quando a mudança é algo que não existia… é uma coisa, agora quando a mudança é: “Esse campo não tinha que ser texto aberto e sim comboBox.” você percebe que houve falha no processo. Ou quando o cliente diz: “Esse módulo de processamento financeiro está errado, os valores não batem.” Bom, agora você tem um problema novo.

Esse tipo de situação pode ser evitada se guiarmos nosso desenvolvimento pelo Domínio.

Mas como guiar o desenvolvimento pelo Domínio?

Em geral, antes de desenvolver um software deve haver todo um processo de análise. Documentação, entrevista com clientes, o cliente deve nomear alguém para ser o suporte do analista, alguém que passará conhecimento a equipe que irá desenvolver.

Muitas empresa contratam alguém que faz Analise de Negócios, esse cara geralmente entende todos os problemas do cliente e interage com a equipe de desenvolvimento, passando as necessidades, avaliando implementações, tirando dúvidas. O trabalho desse profissional limita-se a ser o cara mais bem informado a respeito do projeto ele sabe lidar com o cliente leigo e com o desenvolvedor altamente técnico.

A equipe de Arquitetura, cabe entender os problemas para projetar a forma que o software será desenvolvido, quais soluções resolve quais problemas, e inclusive encontrar partes da implementação que podem ser enviáveis, trabalhando numa solução que tornará a implementação viável.

Mas eu trabalho sozinho em casa, como usar isso?

Quando trabalhamos sozinhos como freelancer, é mais importante ainda usar esse tipo de técnica, já que se perdermos tempo desenvolvendo algo inútil, perdemos dinheiro. Em nossa área nossos projetos demoram. Isso gera lucro a longo-prazo. Lógico que recebemos uma antecipação, podemos acertar pagamentos por fases do projeto, mas mesmo assim, qualquer mudança pode atrasar e vai retardar o lucro.

Então, você terá que ser o analista, terá que entender o problema do cliente, entrevistá-lo, documentar, e gerar um relatórios do problema e da solução para que o cliente leia e possa te dizer se é ou não é esse o entendimento correto.

Criar wireframes e entregar para o cliente validar, é uma ótima solução, criar uma apresentação com todo o funcionamento do software e apresentar pro cliente num telão, além de profissionalizar seu trabalho, vai tirar todas as suas dúvidas e as do cliente sobre o projeto.

Inclua isso nos seus custos e prazos.

Se adotar esses padrões, seus trabalhos fluirão.

Para uma equipe de desenvolvimento é essencial, mesmo que não tenham um Analista de Negócios, eleja alguém no cliente para ser quem vai responder suas dúvidas, tire todas antes de começar a desenvolver, e em caso de erro, faça um refectoring da solução e não tente adaptar para que resolva aquele problema. Use padrões de projeto de softwares, facilitará nessas mudanças quando necessário.

E lembre-se. Mesmo fazendo tudo isso, terá mudanças na hora da homologação. Mas não terá mudanças por não ter entendido o problema.

Pesquise mais sobre Domain-Driven Design.

Abraços

Paulo Teixeira
Post original

 

Permanent link to this article: http://ensina.me/coldfusion/domain-driven-design/

Leave a Reply