Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Este artigo trata da utilização do Domain-Driven Design (DDD) de forma prática, através da criação de um projeto de software do início ao fim. Com o objetivo de demonstrar os patterns propostos pela metodologia.
Para que serve:
Desenvolver um projeto de software, seguindo esta metodologia, coloca a equipe de projetistas e desenvolvedores nos trilhos da orientação a objetos, em direção a um rico domain model. Ela permite que a equipe técnica tire maior proveito dos benefícios oferecidos pelo paradigma. Além de facilitar a comunicação com domain experts, devido ao foco no domínio, sustentado pelo DDD.
Em que situação o tema útil:
O DDD é útil para qualquer equipe de projeto que tenha como objetivo, modelar o domínio do negócio do cliente, de forma eficaz e eficiente. Ele também facilita a boa comunicação entre os envolvidos no projeto, pois permite a criação de um design que reflita o domínio, além de prover extensibilidade e reusabilidade, baseado no uso correto do paradigma orientado a objetos.
Java e Domain-Driven Design na prática:
Modelar sistemas de forma eficiente é um desafio para qualquer equipe de desenvolvimento. Neste contexto, o DDD surge como um apoio para este objetivo.
Este artigo apresenta a implementação, do início ao fim, de um sistema em Java, utilizando os frameworks JSF 2.0 e EJB 3.0, baseado na metodologia Domain-Driven Design (DDD). Desta forma, é possível criar um sistema com todos os benefícios oferecidos pela orientação a objetos, que reflita o domínio do negócio e com a complexidade reduzida, devido aos patterns propostos pela metodologia.
Os frameworks têm o importante papel de facilitar o trabalho da equipe de desenvolvimento, nos aspectos mais técnicos do processo de criação do software.
A metodologia Domain-Driven Design (DDD), apresentada por Eric Evans no livro “Domain-Driven Design: Tackling Complexity in the Heart of Software”, oferece ferramentas para a construção de sistemas com foco no domínio do negócio do cliente.
Ela torna o trabalho da equipe de projeto mais eficiente, pois permite o desenvolvimento de sistemas de “dentro para fora”, isto é, com esforços concentrados na camada de modelo, onde toda a complexidade das regras de negócio deve existir.
Além disso, todo o processo de criação é apoiado na linguagem daqueles que irão utilizar a aplicação (Ubiquitous Language), desta forma, a comunicação entre equipe técnica e domain experts, torna-se mais clara.
A ubiquitous language é uma linguagem estruturada em torno do modelo e deve ser utilizada por todos os membros do projeto para conectar todas as atividades.
Em resumo, o DDD introduz ao processo de desenvolvimento de software:
1. Uma arquitetura em camadas para divisão de responsabilidades (veja o quadro “A arquitetura em camadas do DDD”);
2. A ubiquitous language, que facilita a comunicação entre equipe técnica e domain experts, além de gerar documentação em nível de código;
3. Patterns que simplificam e consolidam o design.
O objetivo deste artigo é demonstrar a utilização prática do DDD, através da implementação de um projeto em Java, com os frameworks JSF 2.0 e EJB 3.0, fazendo uso da API de persistência JPA, dentro de um container Java EE (GlassFish).
Antes de começarmos a trabalhar no objetivo apresentado, precisamos de detalhes sobre o sistema que será desenvolvido.
O DDD propõe uma arquitetura em camadas (veja a Figura Q1) para a divisão de responsabilidades de uma aplicação. Cada uma delas, deve se especializar em um aspecto particular do sistema. Esta especialização permite a criação de um design coeso e de fácil interpretação. O princípio básico é que cada elemento de uma camada, dependa apenas de outros elementos dessa mesma camada ou de camadas inferiores.
A arquitetura proposta pelo DDD é formada por:
1. Camada de Apresentação (User Interface): Responsável por interpretar os comandos do usuário;
2. Camada de Aplicação (Application): Não contém regras de negócio ou código referente ao domínio, apenas coordena tarefas e delega trabalhos;
3. Camada de Modelo (Domain): É o coração do sistema. Responsável por representar o domínio e suas regras de negócio;
4. Camada de Infraestrutura (Infrastructure): Provê recursos técnicos para o sistema, como persistência de dados.
Figura Q1. Arquitetura do DDD.
Sistema de vendas on-line
Uma empresa de organização de eventos lançará a edição 2011 de seu mais famoso evento, o Java in Rio. Este evento consiste em uma semana de atrações diversas para profissionais de TI, que incluem palestras, workshops, minicursos, além de outros.
Cada dia do evento contará com atividades comandadas por grandes nomes da área. O interessado em participar deverá comprar ingressos para os dias de sua preferência.
A organização já tem definidas as datas do Java in Rio, mas ainda não confirmou todos os profissionais que farão parte do ciclo de atrações oferecidas. Como o evento é muito popular, decidiu colocar passes a venda, que darão direito aos compradores trocarem por ingressos do dia que escolherem, quando as atrações forem definidas.
Baseados neste cenário, os organizadores encomendaram um sistema de venda de passes on-line, que permita a venda de até cinco passes (com direito a uma meia-entrada), identificados através de um código único, para cada cliente, ao preço de R$ 190,00 a unidade.
Modelando a aplicação
Tendo em vista o cenário apresentado anteriormente, podemos iniciar a modelagem do sistema de vendas.
Para construirmos uma ubiquitous language eficaz, é importante utilizarmos palavras que façam parte da linguagem corrente dos domain experts ao modelarmos a aplicação. Neste universo os membros do projeto devem discutir a respeito do sistema, para tornar a comunicação mais clara.
O design da aplicação deve estar alinhado à linguagem corrente do negócio. É importante que nomes de classes, atributos, variáveis e assinaturas de métodos, façam parte da ubiquitous language. Assim, a equipe de projetistas e programadores, pode mostrar como elementos do negócio do cliente irão se relacionar dentro do sistema, utilizando um vocabulário familiar aos domain experts. Além disso, um domain expert que tenha algum conhecimento técnico sobre a tecnologia empregada, pode conversar em um nível de menor abstração com a equipe de desenvolvimento, mais facilmente.
Os patterns oferecidos pelo DDD permitirão que a equipe técnica introduza seus próprios termos à ubiquitous language, desta forma, aspectos mais técnicos do processo de desenvolvimento podem ser discutidos com os domain experts, de forma simplificada. Ao invés de projetistas e desenvolvedores falarem sobre DAOs, queries, JDBC, Java Beans e outras coisas que não fazem parte do dia-a-dia de um domain expert, eles poderão se expressar com um nível de abstração mais alto, utilizando termos mais comuns como: entidades, serviços, especificações e repositórios, por exemplo.
Após conversas entre equipe técnica e domain experts, ficou decidido que o sistema deve permitir ao usuário escolher a quantidade de passes que deseja adquirir, informar seus dados pessoais e endereço de entrega, para então, efetuar o pagamento do pedido com um cartão de crédito.
...
