Olá pessoal,
A patterns & practices acaba de publicar o guia “Acceptance Test Engineering”. Esse guia contém informações e métodos importantes relacionados a testes de aceitação. Algumas informações importantes constantes do guia:
Grande abraço e até a próxima,
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:
Roberto Pepato Mellado
IT Insights 