Por que eu devo ler este artigo:Este artigo é útil para arquitetos, programadores, analistas de sistemas e líderes de projetos que buscam desenvolver sistemas de alta qualidade tendo em vista um código-fonte que reflita o domínio e as regras de negócio das empresas. Levando em consideração esse cenário, o principal objetivo deste artigo é apresentar a metodologia de projeto DDD e a técnica de desenvolvimento de software TDD, que visam melhorar a qualidade do software e diminuir os altos custos no desenvolvimento, manutenção e evolução.

Os processos de desenvolvimento e manutenção dos sistemas de grande parte das empresas possuem custos elevados por conta da alta complexidade do problema que os mesmos se propõem a resolver e da baixa qualidade do código e/ou demais artefatos. Dentre os principais fatores responsáveis pela baixa qualidade, podemos citar a documentação desatualizada em relação ao código-fonte, este que não reflete o domínio do negócio, dificuldades em entender o código, duplicidade, pouca ou nenhuma cobertura de testes unitários e de integração, baixa coesão e alto acoplamento entre módulos e classes.

Como solução para os problemas citados, este artigo apresenta a metodologia Domain-Driven Design, proposta por Eric Evans, no livro “Domain-Driven Design: Atacando as Complexidades no Coração do Software”. Com o mesmo intuito, será apresentada a técnica de desenvolvimento e implementação de sistemas Test-Driven Development, que se baseia na construção de softwares através de ciclos de teste – implementação – refatoração. O TDD tem como criador e principal incentivador o engenheiro americano Kent Beck, também criador da metodologia ágil XP. Por fim, serão expostos os benefícios e ganhos, a médio e longo prazo, de se utilizar DDD e TDD no design e codificação de sistemas.

Domain-Driven Design

Fundamentado na experiência de mais de 20 anos de Erick Evans no desenvolvimento de sistemas, o DDD é uma abordagem que reúne um conjunto de boas práticas, padrões, ferramentas e recursos da orientação a objetos que têm como objetivo a construção e desenvolvimento de sistemas de acordo com o domínio e regras de negócio do cliente. Além disso, questões relacionadas ao processo de desenvolvimento, como a necessidade de um estreito relacionamento entre a equipe de programadores e os especialistas do domínio, também são tratadas pela abordagem.

O principal conceito do DDD é o modelo. Este expressa o domínio e negócio do cliente e pode ser criado utilizando desenhos, fluxogramas, diagramas, etc. O importante é que ele represente o negócio do cliente.

Como principais componentes do DDD, podemos listar: a linguagem onipresente, a arquitetura em camadas e os padrões.

Com o intuito de mostrar essa abordagem na prática, será utilizado como exemplo um sistema de reservas de churrasqueira e salão de festas de um condomínio, cujo modelo é apresentado logo a seguir, através do diagrama de classes da UML (vide Figura 1).

Figura 1. Modelo de domínio do condomínio para o sistema de reservas da churrasqueira e salão.

Sistema de reservas da churrasqueira e do salão de festas

O condomínio Parque Novo Mundo, formado por um conjunto de seis prédios, tem aproximadamente 1.200 moradores e uma excelente estrutura para festas e comemorações, sendo oito churrasqueiras e seis salões de festa em sua área comum.

Entretanto, por conta da grande procura por parte dos moradores para reservar estes espaços e da não utilização de um software para auxiliar administradores e moradores no procedimento de reserva destas áreas, o processo de agendamento e controle se torna custoso e propenso a erros.

Visando possibilitar aos moradores do condomínio uma maior facilidade na reserva destas áreas e um melhor controle por parte dos administradores, foi solicitada a uma empresa de desenvolvimento de software a implementação de um sistema de reservas, a partir do qual um morador poderá realizar a reserva da churrasqueira ou salão na data desejada caso ele esteja em dia com as taxas do condomínio e o ambiente já não esteja alocado. Solicitada a reserva, ela ficará pendente aguardando a aprovação do administrador, que verificará a disponibilidade do local. Ademais, concluída essa etapa, o morador poderá cancelar o pedido com até três dias de antecedência.

Linguagem onipresente

A linguagem onipresente ou ubiquitous language é uma das características do DDD que permite a clientes, gerentes de projeto, analistas de sistemas, arquitetos e desenvolvedores “falarem a mesma língua”, evitando assim que membros da equipe utilizem termos que não reflitam o domínio do negócio do sistema.

A não utilização da linguagem onipresente impede e dificulta a troca de informações, ideias e conhecimentos, resultando na implementação de um código-fonte que não reflete o negócio e, com isso, provoca uma maior dificuldade na ...

Quer ler esse conteúdo completo? Tenha acesso completo