Orientação a Objetos e o Modelo Anêmico: Business Objects, Value Objects e Data Access Objects

Olá! Para iniciar a sequência de posts deste blog, gostaria de falar de um problema arquitetura que venho encontrando constantemente nos projetos em que tenho participado. O que vamos discutir aqui são os problemas que um Modelo de Domínio Anêmico, ou Anemic Domain Model pode nos causar.

Nos últimos projeto de sistemas que tenho participado, verifiquei que a estruturação de uma arquitetura n-camadas, tem sido baseada na combinação de diversos padrões de desenho, notadamente a trinca BO + VO + DAO.

Assim, o usuário executaria alguma operação na interface do sistema, que conversaria com algum objeto da camada de objetos de negócio (BO). O objeto de negócios por diversas vezes precisa armazenar informações dentro do banco de dados e utiliza objetos da camada de acesso a dados para isso (DAO).

A proposta do objeto de valor (VO) é funcionar como meio de transporte entre essas duas camadas, evitando assim overhead de comunicação entre as camadas que podem estar em processos de execução diferentes.

Eu fiz questão de destacar a palavra podem, pois apesar do padrão VO ter sido criado exatamente com o propósito de trafegar entre camadas que executam processos diferentes, em 90% dos casos que tenho visto ele não é usado dessa maneira. A minha percepeção é que na maioria das vezes, existe um uso indiscriminado dos design patterns, sem um entendimento completo da proposta de solução que os mesmos apresentam. Explico:

O pattern VO é um padrão que deve ser utilizado para trafegar objetos “de domínio” entre processos. O fato é que ele vem sido utilizado como objeto de transporte entre camadas que residem no mesmo processo. Um BO que reside na mesma máquina e no mesmo processo de um DAO (tipicamente uma referência direta em C#) utiliza um VO para transporte de objetos de domínio entre essas duas camadas. E qual é o problema disso ? Um grande problema:

Se voltarmos aos preceitos iniciais da orientação à objetos, vamos perceber que é desejado que objetos sejam entidades com dados e responsabilidades. O que estamos fazendo ao armazenar as operações de negócio num BO e os dados num VO ? Estamos quebrando uma das principais regras da orientação à objetos e introduzindo um estilo procedural de implementação. Um objeto VO, que é composto apenas de getters e setters, tem quais comportamentos ? E um objeto BO que aramazena comportamento mas não controla dados e/ou seus estados, tem quais informações para serem operadas sobre seus comportamentos ? Percebem a incoerência na quebra de um objeto “rico” de domínio em dois objetos: BO + VO ?

A utilização do VO para transporte de dados entre camadas que residem num mesmo processo deve ser evitada pois nos leva a construção de modelos anêmicos. Tais modelos, considerados burros, contém apenas dados que são transportados de um lado para o outro mas que não sabem o que fazer com esses dados.

Existem soluções para o para o problema arquitetural descrito no tópico desse post, como por exemplo o pattern Repository.

Nos próximos tópicos estarei discutindo um modelo de solução arquitetural para evitar o problema descrito acima.

Grande abraço e até o próximo post
Referências:

http://martinfowler.com/bliki/AnemicDomainModel.html
http://martinfowler.com/eaaCatalog/repository.html
http://fragmental.com.br/wiki/index.php?title=Fantoches
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
http://fragmental.com.br/wiki/index.php?title=Desenvolvendo_Sistemas_OO_Com_Padr%C3%B5es_de_Neg%C3%B3cio

Tags:

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


%d blogueiros gostam disto: