Java EE & DDD – Críticas e Sugestões

18/01/2014 at 19:02

Java EE – Bean/POJO

O framework Java EE é naturalmente baseado em bean e classes POJO – Plain Old Java Object, classes que não sabem, apenas “carregam” dados, ou seja, são populadas por algum mecanismo com os dados do Banco de Dados, e podem ser usadas pelas outras camadas da aplicação.

A anotação @Entity é justamente para declarar quando uma classe é um POJO populado pelo EntityManager. Os EJB são classes de serviços de negócio, ou seja, aquelas que sabem o que fazer com as classes de entidade, sabem como realizar CRUD, validar e relacionar.

DDD

Resumidamente para esta didática, DDD prega que as classes de entidade não devem ser apenas para carregar dados, eles chamam isso de classe anêmica, dizem que o correto é que essas classes saibam realizar CRUD delas mesmas e muito mais.

Críticas e Sugestões

DDD é interessante, sou partidário da “Ubiquitous Language”, das camadas da arquitetura proposta e do foco no modelo, mas tratando-se de sistemas corporativos, ou seja, predominantemente sistemas de informação, eu respeitosamente descordo da crítica a “classes anêmicas”, pois acredito que trata-se de modismo e/ou febre e portanto temos que ter muito cuidado na adoção. Sugiro aprender tudo sobre DDD mas ignorar essa falácia contra “classes anêmicas”, e usar o conceito de “serviços de negócio” EJB dentro do modelo com MOR – Mapeamento Objeto Relacional baseado em POJO.

Observe que em sistemas de gestão que se propõem a atender diversos tipos de clientes em diferentes regiões do país ou até mesmo fora, estão sujeitos a diferentes abordagens administrativas, não é o cliente que se adapta ao software, mas sim o contrário, é possível então que um cliente opte por controlar os autônomos pelo RH e outro que opte por controlar pela tesouraria.

Acredito que seja perda de flexibilidade ter uma classe Autônomo com seus dados e que saiba realizar CRUD utilizada pelo RH e pela tesouraria, estaríamos violando os princípios GRASP criando uma classe com baixa coesão. Com um POJO e dois EJB o RH irá realizar validações e relacionamentos diferentes da tesouraria, são dois pontos de vista de negócio diferentes para a mesma entidade autônomo.

Por fim, tenho que considerar outro agravante, para criar uma aplicação Java EE baseada num banco de dados modelado em Delphi sem OO, ou seja, quando criávamos primeiro o banco de dados (hoje devemos criar primeiro o modelo OO e depois pensar em persisti-lo), não recomendo DDD pela enorme impedância Objeto/Relacional que acontecerá.

Portanto cuidado, não use DDD sem saber se realmente é possível, e não propague a crítica de “classes anêmicas” só por que a comunidade DDD o faz. Cada um deve ser considerado e avaliado conforme as circunstâncias.

Personagens Java vs Personagens Delphi

15/12/2013 at 00:16

Introdução

Programadores Delphi estão acostumados a escrever regras de negócio direto no .pas do form, botões de incluir, alterar, excluir e salvar são casos recorrentes de eventos com regra de negócio. Isso faz sentido para o Delphi, pois não se considerava programação distribuída nem balanceamento de carga, disponibilidade ou escalabilidade horizontal, apenas vertical. Não era esse o objetivo dos softwares a serem desenvolvidos. O Delphi atraiu (propositalmente) no fim da década de 1980, início da década de 1990, programadores Clipper que atuavam em pequenos CPDs de indústrias, comércio e escritórios construindo aplicações monolíticas, maravilhados pela programação visual com drag/drop e SQL. Alguns programadores apostaram alto ao usarem Delphi em aplicações corporativas acreditando nas promessas da Borland/CodeGear/Embarcadero, e no contagiante RAD – Rapid Application Development, acarretando em alto débito técnico.

Bem, se você está aqui, provavelmente se deu mal como eu. Mas nem tudo está perdido, abaixo vou traçar um paralelo didático dos personagens dessas duas plataformas.

Personagens em Paralelo

Considerando apenas J2EE, ou seja, aplicações corporativas predominantemente web, e como exemplo os arquivos Uni1.dfm e Uni1.pas de um novo form Delphi:

  • O Unit1.dfm do Delphi está para a página html
    a diferença é que em Delphi escrevenos o DFM sempre com drag/drop.
  • O Unit1.pas está para o ManagedBean.
  • Os EJBs são como as classes que você implementa no DataSnap
  • A JPA está para o DataModule
    a diferença é que não se escreve SQL mas sim JPQL – Java Persistence Query Language.
  • Uma classe Java anotada com Entity é como se fosse o FieldList do DataSet do Delphi
  • Hibernate, EclipseLink, TopLink, etc., estão para o DBExpress, ADO, BDE, etc., ou seja, é o componente de acesso a banco de dados (relacional ou não)
  • TForm do Delphi não tem nada a ver com a tag form do html, prefiro dizer isso pela pouca semelhança que têm e pela grande confusão que causam quando comparados

Ciclo completo básico

O ciclo completo que a aplicação Java EE com JSF percorre no clique de um botão, p.e., é basicamente:

  • O usuário clica no botão rendezidado em html
  • O ManagedBean responde com um método público que invoca algum método do EJB
  • O EJB processa conforme as regras de negócio e realiza acesso a dados se necessário invocando a camada de acesso a dados que pode ser o Hibernate por exemplo

Importante

O mais importante é vencer o hábito e não implementar regra de negócio no ManagedBean, lugar de regra de negócio é no EJB. Pense sempre que a camada visual pode ser substituída por um WebService, ao fazer isso o ManagedBean não será utilizado, apenas os WebMethods SOAP ou Paths dos EndPoint RESTFul.

Ou seja, @ManagedBean (JSF), @WebService (SOAP) e @Path (REST), nunca devem conter regra de negócio, eles são apenas as classes de interface da sua aplicação, digo interface no sentido de fachada. Essas três classes apontam/usam os mesmos EJB que agregam as regras de negócio num único lugar.

Existirão casos em que essas três classes apenas repassam chamadas para os EJBs, tornando-as aparentemente inúteis, mas isso não é verdade, essa repetição de código é um preço barato a se pagar pela flexibilidade. Lembre-se você está construindo uma aplicação corporativa, pense sempre que ela vai crescer muito e se tornar complexa.

Outro conceito importante, para quem tem afinidade com UML, consideramos a realização do caso de uso como sendo o diagrama de sequência, pois bem, aquela primeira classe do diagrama que recebe os estímulos do ator é o ManagedBean ou o WebService. Portanto em casos de telas complexas o ManagedBean não é uma das classes mais bonitas ela pode ser caótica, o importante é construir e manter os EJBs com bom design de classes, eles são a API, o kernel da aplicação, código puro, nenhum acoplamento com camada visual, de forma que se possa realizar testes unitários inclusive.