Neste post irei abordar uma introdução à modelagem de domínios, com algumas boas dicas e práticas, através de exemplos elaborados de forma simples em que o leitor entenda e compreenda a ideia proposta.
Todos os softwares ao serem projetados são relacionados a alguma atividade ou interesse do usuário. Este interesse em que o usuário aplica o programa é o Domínio do software.
Um domínio geralmente está ligado ao mundo físico, por exemplo, um programa de reservas de ingressos de jogos de futebol, envolve pessoas reais entrando em estádios de futebol reais. Alguns softwares são intangíveis, o domínio de um software bancário, por exemplo, envolve o dinheiro, finanças. Porém, existem exceções, como um software IDE(Integrated Development Environment), ou Ambiente integrado de desenvolvimento, que gerencia o próprio desenvolvimento de softwares.
Para criar softwares que desempenham as atividades de forma coerente para os usuários, a equipe de desenvolvimento ou o desenvolver, devem trazer consigo muitos conhecimentos sobre o domínio do projeto. A quantidade de conhecimentos sobre o assunto pode muitas vezes ser absurda, para isso existem os Modelos, que são uma forma de organizar e selecionar os conhecimentos de um domínio, com coerência para criar uma boa estrutura.
Um modelo não se trata de um diagrama específico, é apenas uma espécie de rascunho “sofisticado” de como virá a ser o diagrama final.
Observe, abaixo, uma modelagem de domínio de um software de caixa eletrônico bancário. O domínio, neste exemplo, se trata de clientes movimentando seu dinheiro. Realizando, assim, operações e movimentações de suas contas através do software.
O primeiro modelo elaborado com todas as informações poderia ser algo deste tipo:
Após um refinamento das informações e aplicação dos princípios de modelo, poderíamos melhorar o exemplo anterior e chegar a um novo, algo assim:
Este post apenas introduz a ideia de modelagem de domínios, este exemplo poderia ser mais refatorado, mas deixo o interesse de ir além aos leitores.
Para se aprofundar mais sobre este assunto, recomendo a leitura do livro referênciado.
Referências:
- EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. New York: Addison-Wesley, 2004.
- BRIÃO, W, E. Trabalho de Programação Orientada a Objetos. Rio Grande: IFRS, 1°Sem/2013. Acesse neste link.
Nenhum comentário:
Postar um comentário