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.