Ruby on Rails – Onde colocar as regras de negócio?
Recentemente eu li no fórum do RubyOnBr um post com a a seguinte dúvida: onde deve ser escrita a lógica de negócios da aplicação? Pesquisei um pouco mais no fórum e vi mais gente com essa mesma dúvida inclusive alguém disse que coloca as regras de negócio no controller porque eu aprendi fazer assim no Java. Mesmo esse assunto já tendo sido bem discutido é fato que MUITA gente faz da forma errada e que não acredita que está fazendo errado. Não só está errado como está prejudicando o desenvolvimento e a manutenção da aplicação entre outras coisas. Apesar de muitos acharem que seus sistemas são OO, a Orientação à Objetos é muito pouco utilizada.
Antes de começar explicar porque as regras de negócio devem ficar no model, é importante frisar que isso só fará sentido e você só irá acreditar que o que estou falando faz sentido quando o seu modelo de domínio estiver com o mínimo de qualidade, em outras palavras, se seu modelo estiver mal desenhado seu controller tenderá a ter regras de negócio.
O Controller é o componente com inteligência o suficiente para saber qual operação invocar no Model, ou seja, sua função é apenas receber as chamadas que vem da view e direcioná-las para o modelo, o máximo que ele irá fazer é gerenciar um fluxo de chamadas.
Alguns vão ficar pensando pô mais eu fazia em Java usando alguns patterns e ficava massa, eu criava uns VOs só com o atributos e dezenas de get() e set() e depois meus BOs e eu achava minha arquitetura ótima, ficava tudo bem separado. O ideal é esquecer que existe essa forma de se trabalhar. Será que o que você estava fazendo não era programar em C ou Pascal e salvar .java? Leia mais aqui.
Minha sugestão é começar estudando um pouco sobre Domain Driven Design. Comece seu software desenvolvendo um bom modelo de domínio, lembre-se que você pode ter entidades de negócio que não serão persistidas, isso é importante para você não deixar de representar objetos do domínio e colocar as regras no controller. Quando seu modelo de domínio estiver razoavelmente bem definido tente desenvolver agora não mais colocando nenhuma regra de negócio no controller e você vai ver que se torna bem mais fácil, você acaba conseguindo utilizar muito melhor OO e vai ver que sua repetição de código irá diminuir bastante, isso sem falar nas referências cruzadas entre as classes.
Isso que foi explicado não vale apenas para rails vale pra Java, .Net, etc. Recomendo a leitura do artigo A dieta dos Controllers do Fábio Akita, ele fala de como “esvaziar” seus controllers já dando exemplos de como fazer usando REST, são exemplos bem didáticos. Outro artigo interessante é MVC e Camadas do Phillip Calçado. Por último se você é fã de VOs e BOs comece lendo esse mini artigo de 2003 escrito pelo Martin Fowler Anemic Domain Model, talvez ele falando alguém acredite. 
De tudo isso que falei nesse post, nada é novidade, mas resolvi fazer esse post para tentar divulgar a forma certa de fazer as coisas. Precisamos mudar essa imagem que foi criada, as pessoas precisam entender que fazer modelos de domínio anêmicos é um ótimo começo para o software dar errado e para as regras de negócios se propagarem por todas as camadas.
