Fragmental

O Paulo Vasconsellos lá do finito ensaiou sua opinião sobre como código não pode representar a documentação sobre um processo de negócios. O post que originou a conversa é bem fraquinho, mas o ponto é bom.

Basicamente a idéia é que não dá para confiar no código porque ele possui o que Joel Spolsky catalogou como ‘leaks de abstração’ em um dos seus artigos mais citados. ~Tenho que admitir que isso pode ser verdade na maioria dos casos mas apenas porque as pessoas ainda não aprenderam o conceito simples de separação de responsabilidades, e isso é muito pior na cultura .Net que é a do autor do artigo original.

Imagina que temos um processo de negócio automatizado num software OO. A coisa é simples, o clássico e onipresente exemplo de adicionar usuários a um grupo:


void adicionarUsuario(Usuario u, Grupo g){
g.adiciona(u);
}


E como estamos falando de um software OO as regras de negócio estão nos respectivos objetos (grupo e usuario) e não nesse método de serviço. Muito bem, eu consigo gerar uma documentação em fluxograma, UML, o que for desta sequência simples de instruções imperativas. O problema é que software não é simples assim.

Eventualmente nós precisaremos persistir a alteração feita no banco de dados.


void adicionarUsuario(Usuario u, Grupo g){
g.adiciona(u);
repositoriousuarios.atualizar(u);
}


E possivelmente precisamos saber se o usuário logado possui direito a fazer esta alteração, esse é um requisito não-funcional de segurança. Adicionar um log também é útil para auditoria.


void adicionarUsuario(Usuario modificador, Usuario modificado, Grupo g){
if(podeAlteraroutrosUsuarios(modificador){
g.adiciona(modificado);
repositoriousuarios.atualizar(modificado);
logger.info("Alterou");
}
else{
throw new IllegalQualquerCoisaException();
logger.error("Tentou alterar");
}
}


E isso pode piorar ainda mais. Agora utilize o código acima como documentação de negócios por favor. Mostre ao seu cliente e peça para ele tentar te explicar. não dá, né? E por quê? Porque cada uma destas coisas são conceitos ortogonais, que deviam ser implementados por técnicas de AOP e não embolados no meio do código de negócio.

Domain Driven Design possui a modelagem de negócios no código como sua essência. Um dos pontos que mais causam dúvidas, por exemplo, é o da diferença entre Repositórios eDataMappers (DAOs no mundo Java EE). A diferença é que eu coloco um repositório num diagrama de negócios (ainda que chame de outra coisa) mas não coloco um DataMapper . E por quê? Porque a responsabilidade de um Repositório é referente à objetos que mapeiam o negócio enquanto a responsabilidade de umDataMapper é transformar objetos em tabelas (ou coisa do gênero) e objetos ou tabelas não são conceitos de negócio. Assim ainda que um DataMapper implemente um Repositório eles são tratados sob pontos de vista bem diferentes para análise de sistemas.

No passado nós tínhamos uma discrepância enorme entre os modelos de negócio e o modelo físico do software. Há mais de vinte anos que não há motivo para esta diferença existir, exceto uma cultura dominante. O problema, como sempre, está nas pessoas.

Model-Driven Development, conjunto de idéias que Domain-Driven Design faz parte, é exatamente sobre isso. Por enquanto nós ainda precisamos educar os desenvolvedores para que usem as ferramentas de maneira correta, num futuro próximo eu espero que Domain Specific Languages poupem este trabalho na maioria dos casos.

This entry was posted on Friday, July 27th, 2007 at 1:40 am and is filed under .net, arquitetura, comunidade, domain.driven.design, domain.specific.languages, engenharia, java, orientacao.a.objetos, programando, soa. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.