Arquiteturas...

Ao iniciar o desenvolvimento de qualquer software, uma das primeiras atividades desempenhadas pelos desenvolvedores (especialistas em computação) é a definição da arquitetura do mesmo. Essa tarefa custuma ocorrer logo após uma definição, ou melhor, do levantamento dos requisitos do negócio a ser tratado, sendo assim, o que for definido nesta etapa deverá ser considerado durante todo o tempo de vida do projeto. Acontece que essa não é uma atividade trivial. Com tantos padrões, técnicas, modas, conceitos mal entendidos, frameworks entre outros parâmetros, muitas vezes ficamos em dúvida do que de fato utilizar. Uma coisa é clara, desejamos que o código-fonte dos nossos softwares estejam cada vez mais próximo do domínio do problema, fazendo com que a comunicação entre desenvolvedores e especialistas do negócio utilize uma linguagem comum. Como uma tentativa de atingir esse nível de qualidade do código e ter uma maior aproximação dos envolvidos no projeto, o paradigma de Domain-Driven-Design (DDD) apresenta-se como uma abordagem extremamente útil e prática a ser considerada. Através do DDD, várias diretrizes podem ser seguidas para a elaboração de uma arquitetura transparente e mais próxima do domínio como desejamos. Essas diretrizes não são relacionadas apenas com o código-fonte em si, como é o caso do uso de determinados padrões de projeto, tal como o tão falado e confundido Repository. O DDD contempla também a elaboração de uma linguagem comum (chamada de Ubiquitous Language) a ser usada entre os envolvidos no projeto. Isso significa que os desenvolvedores devem nomear seus artefatos (classes, métodos, atributos, etc) de acordo com o negócio tratado. Isso também não quer dizer que os desenvolvedores não possam usar palavras do seu próprio jargão, por exemplo, o conceito de repositórios (pattern Repository) é comumente usado nessa comunicação, mas seu conceito deve estar bem claro para ambos os lados.
Outra discussão que segue é em relação às camadas da arquitetura. A tradicional dúvida, "Onde devo colocar as regras de negócio?" A tradicional separação em classes do tipo Business Object, Value Object, Data Transfer Object, Classes de controle, entre outras, nos perguntamos onde se encaixa a orientação a objetos, essa forma tradicional é muito estruturada. Esses dias conversando com um amigo no Google Talk ele me perguntou: "me diz onde eu deveria criar meu objeto 'Notícias' que vai puxar os dados no BD, usar uma DAO? e as validações, regras de negócio?". Para responder a pergunta, abaixo consta um pequeno diagrama de classes envolvidas na solução.
A classe News é a classe de domínio. Nessa solução, o padrão Repository está sendo implementado como uma DAO, porém perceba que a classe Client (classe que exemplifica o uso dessa estrutura criada, poderia ser uma action do Struts ou lógica do VRaptor por exemplo) tem associação apenas com a interface NewsRepository, isso é importante para não termos um forte acoplamento com a implementação. A classe concreta NewsDao então implementa a interface NewsRepository para conter de fato a implementação da interação dessa entidade com o banco de dados. Perceba também que a classe News não possui nenhum método de negócio digamos, mas caso existisse algum método que alterasse o estado dos atributos este deveria ser criado nessa classe, e não em uma NewsBO. Quando temos uma classe que contém os métodos de negócio e os atributos dizemos que ela possui um alto nível de coesão, que é um ponto forte dessa implementação. Quanto a questão de validação do estado dos atributos, fazendo uso de um framework como o HibernateValidator (que inclusive serviu de inspiração para a criação da JSR-303 - Bean Validator) a tarefa torna-se simples e declarativa.

Para mais informações a respeito de DDD, peço que chequem os artigos contidos na InfoQ. Nesse espaço pode ser encontrado muito conteúdo bom sobre Java, arquitetutura, entre outros.

[]s