Specifications (DDD) com SAP Business Rules Management

Este post é apenas uma dica. Ontem, um amigo me questionou sobre como ele poderia facilitar a manutenção de regras de negócio que, apesar de simples, são alteradas com muita freqüência no seu projeto. Ele não conhecia rules engines, tampouco sabia que a SAP, no Composition Environment, disponibilizou a Business Rules Management (BRM).

BRM é um mecanismo de processamento que permite que business experts declarem e gerenciem regras de negócio sem ter de programá-las numa linguagem imperativa. Essencialmente, este ambiente encapsula e desacopla as regras das aplicações que as utilizam, provendo um conveniente grau de flexibilidade.

Isolar as regras de negócio das aplicações, permite que business experts e os autores das regras façam atualizações de forma dinâmica sem quaisquer alterações nas demais aplicações ou processos.

Particularmente, acredito ser um recurso bastante útil para regras que representam fórmulas, cálculos e classificações, por exemplo. Nada mais que isso, creio. Recentemente, identifiquei algumas situações onde essa solução se encaixaria e uma delas é a definição de Specifications.

Specification é um conceito que ganhou a “menção honrosa” de pattern depois que Domain-Driven Design se alastrou rapidamente em sites, blogs e fóruns. Contudo, podemos dizer que Specification é algo utilizado para testar se um objeto satisfaz a um critério. Verificar se um cliente tem direito a um desconto diferenciado, por exemplo.

A maioria das engines provê recursos que facilitam bastante o dia-a-dia de quem escreve/mantêm as regras, tais como: DSLs, IDEs e recursos de avaliação como Decision tables (que te livra de escrever uma montanha de if-then).

Apesar de ser mais utilizada para controlar o fluxo de processos executáveis (BPM), as regras podem ser invocadas de dentro de outras aplicações, através de uma casca EJB ou Web Service.

Finalizo com uma pergunta sobre o maior impeditivo na tentativa de alcançar os reais benefícios desse tipo de solução: Quantos consultores e business expert estão capacitados nesse tipo de recurso?

Respostas sobre SAP para desenvolvedores

Com este post eu tentarei esclarecer as dúvidas mais recorrentes de desenvolvedores de software interessados em seguir carreira como consultor SAP. Tenho visto em fóruns e recebido alguns e-mails com estas perguntas, então vou dar a minha contribuição (com base em minhas experiências e opiniões) para nortear algumas pessoas sobre quais caminhos seguir.

Consultor especialista em que?

A principal dúvida é sempre a diferença entre os “tipos de consultores SAP”, ou seja, suas áreas de atuação. A primeira coisa que precisamos ter em mente quando nos interessamos pelas soluções SAP é que existem duas linhas de profissionais: os consultores funcionais e os consultores de tecnologia – a diferença é clara, mesmo que existam áreas onde possamos mesclar o funcional com o técnico.

Os consultores funcionais são profissionais que detém o conhecimento sobre os processos de uma determinada linha de negócio, e como estes estão mapeados nos aplicativos. Em geral, um consultor funcional é especialista em um módulo do SAP – que são identificados por aquelas siglas que vemos em anúncios de empregos🙂 (ex.: FI, MM, SD, PP e etc.) – e trabalha mais próximo ao cliente na definição dos processos de negócio e utilização do sistema. Resumindo, os consultores funcionais sabem como trabalhar as informações dentro das soluções SAP e estão mais ligados ao negócio do que a tecnologia.

Os consultores de tecnologias SAP são os que conhecem a estrutura técnica das soluções e sabem como customiza-las e integra-las com outras aplicações. Resumindo: implantar, manter, customizar, desenvolver e compor novas soluções é o papel deste tipo de consultor. Como em qualquer processo de automatização, o trabalho dos consultores de tecnologia é tão importante quanto o dos funcionais.

Outra dúvida que eu gostaria de pontuar é como aprender e começar a trabalhar com SAP. Depois de definido o caminho que se deseja traçar (funcional ou técnico), a forma mais comum de aprender a utilizar as soluções da SAP é participar de uma academia ministrada pela própria empresa ou por parceiras educacionais. As academias são treinamentos focados em um módulo ou tecnologia SAP. São caras! Por isso é importante estar seguro daquilo que pretende fazer.

O que está mais próximo do seu perfil? Quais são as oportunidades profissionais após o treinamento? Qual a demanda do mercado na sua região? Que outros conhecimentos além da academia são necessários para atuar como consultor?

Estas questões devem ser observadas com cuidado antes de pagar caro por um treinamento desses. Como eu havia dito, existem também outras formas de obter conhecimento. Entretanto, seja por dificuldade em encontrar materiais, traçar um roteiro de estudos ou até mesmo contato com o próprio ambiente, ser um autodidata é difícil (e às vezes desestimulante). Nestes casos, as experiências anteriores são de grande importância na formação deste profissional.

Sou programador e quero atuar em projetos na plataforma SAP. Vou ter que aprender ABAP?

Depende. Esta resposta está ligada a área que você pretende atuar. Hoje é perfeitamente possível escrever soluções relacionadas a SAP usando linguagens mais populares (como Java e .NET) com uma curva de aprendizagem reduzida. Por outro lado, alguns recursos ainda são feitos usando-se apenas a linguagem da SAP.

E as certificações? É um requisito para atuar como consultor?

Sem querer entrar no mérito de que certificações provam ou não que você está apto a desenvolver alguma atividade (que a maioria delas não prova mesmo), eu diria que é bastante complicado iniciar ou conseguir algo interessante sem elas. Quem é experiente na área sabe o quanto este pensamento é mesquinho, mas é assim que funciona – alguns profissionais usam suas certificações como forma de ter reconhecimento por intimidação . Em alguns momentos, as empresas precisarão de profissionais certificados e as melhores oportunidades exigem isso. IMHO, o caminho é: aprender, pôr em prática e depois se certificar.

Pergunta de um desenvolvedor/arquiteto Java: Vale a pena estudar SAP Netweaver ou devo continuar me especializando em Java apenas?

Sim, vale a pena! O primeiro motivo é que você vai continuar desenvolvendo software da mesma forma que antes, vai continuar escrevendo código Java usando padrões de mercado e frameworks da moda. Em última análise, o Netweaver é composto por um servidor JEE como qualquer outro. O segundo motivo é que o mercado de SAP tem uma demanda grande por desenvolvedores qualificados e experientes. É ai que você entra! E é aqui que sua experiência em desenvolvimento de software é um diferencial (pois uma academia, por melhor que seja, não substitui anos de experiência).

Quanto ganha um consultor SAP?

Creio que este seja o ponto de maior interesse para a maioria. A variação de remuneração é grande e depende de uma série de fatores: localização, qualificação, experiência, os mesmos de sempre. O que devemos condierar é que, como qualquer profissional especialista em alguma coisa, o consultor é, em geral, bem pago. Agora não se iluda! Quem se limita apenas à criação de relatórios não terá a mesma relevância (e conseqüentemente remuneração) que um consultor funcional ou especialista técnico.

A cada dia cresce mais a demanda por profissionais da área de SAP, e para nós desenvolvedores isso se tornou cada vez mais atrativo. Agora além de “obter o cadastro de produtos do ERP”,… estamos trabalhando em soluções com um maior valor agregado, e o melhor de tudo: aproveitando tudo o que sabemos fazer!

Fica ai a dica para os interessados…

Entrevista sobre Domain-Specific Languages com Phillip Calçado

Tirando a poeira do blog com um conteúdo bem bacana. Segue o primeiro post (de muitos, eu espero) que visam discutir temas interessantes, em português, com profissionais que se destacam sobre o assunto.

O tema de hoje é: Domain-Specific Language. E quem vai responder as perguntas é ninguém mais que Phillip Calçado. Baseado em Melbourne, Austrália, Phillip é um experiente arquiteto e desenvolvedor de softwares atuando em grandes projetos na ThoughtWorks.

Laércio Queiroz: Vamos começar pelas definições. Como você define uma Domain-Specific Language?

Phillip Calçado: Uma DSL é uma linguagem estritamente relacionada com um domínio de aplicação. Por ser tão ligada a um domínio em específico ela é muito poderosa dentro dele e, provavelmente, muito ineficiente quando se trata de coisas que fogem a este domínio. Um bom exemplo é HTML. É uma linguagem específica para o domínio de definição de documentos em hipertexto. Se você for descrever um documento em hipertexto para a web utilizar HTML te dá poder e possibilidades; mas se você quiser,digamos, construir uma interface desktop ela não te ajuda muito.

Da mesma forma Java e C# são linguagens genéricas (GPLs – General Purpose Languages). Com estas linguagens você consegue descrever vários tipos de domínios com relativa eficiência mas elas não são particularmente excepcionais em nenhum deles.

lqueiroz: O conceito de DSLs não é novo. Na sua opinião o que fez o mercado dar maior atenção a este técnica agora?

pcalcado: Sim, DSLs são utilizadas há décadas em diversas plataformas de desenvolvimento. O interesse ressurgiu basicamente por dois motivos, creio. O primeiro deles foi à popularização de linguagens que tornam a criação de DSLs algo mais fácil, como Ruby. Hoje usamos dezenas de frameworks e bibliotecas que são -ou dizem ser -DSLs para esta plataforma e cada vez mais as pessoas estão ficando habituadas com e recebendo os benefícios desta abordagem. Engraçado que algumas pessoas estão usando termos como “Ruby-style” para estas técnicas, algo que não faz justiça ao fato que Ruby é apenas um usuário destas técnicas, que foram criadas, definidas, nomeadas e estão presentes de maneira mais profunda em outras plataformas.

Outro motivo é a necessidade de modelar o domínio com ferramentas mais poderosas. Nós usamos técnicas como Domain-Driven Design para tornar o nosso modelo de objetos mais próximo aos conceitos que estamos modelando –o negócio– mas ainda existe muito ruído causado por limitações técnicas. Um passo a frente é nos livramos dos objetos –ou qualquer outro conceito de engenharia de software- como unidade utilizada para modelagem. Objetos são um conceito artificial, não existem no domínio modelado são apenas uma ferramenta. Ao invés de usar a linguagem para modelar objetos que por sua vez modelam o domínio nós modelamos o domínio diretamente na linguagem utilizada.

lqueiroz: As DSLs podem ser classificadas em dois grandes grupos: Textual DSLs e Graphical DSLs. Considerando-se que as duas abordagens têm a mesma intenção, quais as motivações que definem qual o tipo mais adequado de DSL numa determinada situação?

pcalcado: Linguagens de programação, sejam DSLs ou GPLs, podem ser de diversos tipos. Nada impede que você programe utilizando musica ou braile ao invés de texto ou gráficos.

A escolha entre usar (ou criar) uma DSL gráfica ou textual depende do que se quer fazer. Durante décadas nós construímos mecanismos fantásticos para lidar com programas escritos em texto, então uma DSL textual se aproveita disso. Da mesma forma uma DSL gráfica pode ser amigável e/ou representar melhor um dado domínio.

Não existem muitas regras aqui, geralmente a decisão é focada em quem vai usar a linguagem. Se sua DSL vai ser utilizada por programadores profissionais geralmente eles são mais eficientes e lidam melhor com ferramentas textuais, se for usada por clientes e pessoas não tão qualificadas tecnicamente o ideal pode ser uma estrutura de assistentes e editores gráficos.

lqueiroz: Outra interpretação que vem causando confusão é a diferença entre os dois tipos de Textual DSLs: Internal x External. Qual a diferença entre as duas? Em qual momento deve-se escolher por um tipo?

pcalcado: DSLs Internas são aquelas que são criadas dentro de uma linguagem, uma DSL interna está limitada pela sintaxe da linguagem hospedeira. Uma DSL externa e uma linguagem gerada para ser processada por um parser e interpretada ou compilada para um formato executável.

Existem vantagens e desvantagens nas duas estratégias. Se você utiliza uma DSL Interna não precisa criar um parser, compilador ou interpretador: usa os da linguagem hospedeira, o que facilita muito as coisas. Por outro lado, com esta estratégia você perde a liberdade de sintaxe: sua DSL tem que ter uma sintaxe compatível com a linguagem hospedeira. Considere por exemplo o JMock, um framework de mock objects em Java. Apesar do JMock lidar com conceitos bem diferentes de Java o código que você escreve utilizando sua DSL ainda deve ser compilável pelo compilador Java.

Da mesma forma, se você utiliza uma DSL externa vai precisar escrever algum programa que leia e interprete essa linguagem. Ainda que ferramentas como o ANTLR tornem este processo bem simples o trabalho ainda existe e é considerável. A vantagem é que sua linguagem pode ser definida na sintaxe que você quiser já que quem escreve o parser é você.

lqueiroz: Um esforço considerável é exigido quando se pretende criar uma Textual DSL decente. Talvez por isso é mais freqüente a adaptação de uma linguagem (como: Ruby, Java ou C#) usando-a como base para emular as características de uma DSL. Os casos de uso dessas adaptações, em geral, limitam-se a facilitar a configuração de um framework ou subsistema (o que é conhecido também por configuration code). Este é a único contexto onde uma language adaptation se encaixa?

pcalcado: Você adapta uma linguagem para diversas coisas. Uma delas é criar uma DSL interna, neste caso você apenas usa a linguagem como base para criar outra, você não está preocupado em obedecer a convenções ou manter conceitos. Por exemplo você pode criar uma DSL procedural utilizando como base uma linguagem orientada a objetos.

Outra maneira é quando você não está interessado em criar uma outra linguagem, apenas em torna-la mais eficiente e/ou legível em um certo contexto. Um bom exemplo é Criteria API no Hibernate. Essa API usa um estilo chamado method chaining, algo que é comum em outras linguagens mas não faz parte do estilo que usamos em Java. Seria possível utilizar o estilo de Java mas com a adaptação os usuários da linguagem –nós- podem descrever em uma linha o que necessitaria de uma dezena se seguíssemos o estilo normal. Ainda assim ao utilizar Criteria API estamos preocupados em usar corretamente os conceitos da linguagem Java como objetos, classes e métodos.

lqueiroz: Tem sido comum ver exemplos de Fluent Interfaces que servem apenas para tornar o código mais legível. Esta legibilidade é uma conseqüência ou é o principal intento desta técnica?

pcalcado: Eu considero o termo Fluent Interface algo bem confuso. Segundo um de seus autores e principal evangelista, Martin Fowler, Fluent Interfaces são basicamente sinônimos de DSLs internas. Eu não consigo aceitar muito bem essa definição e usava o termo para algo diferente. Como lutar contra o autor não é algo muito inteligente devo passar a chamar minha visão sobre Fluent Interfaces –adaptações feitas na linguagem apenas para torna-la mais legível/eficiente- de outra coisa. Na verdade estou em busca de um nome.

Falando sobre legibilidade e DSLs, não existe uma reação real direta. Uma DSL não precisa ser parecida com linguagem natural ou mesmo sem algo facilmente legível. Mesmo quando a DSL é entendida pelos especialistas no domínio isso não quer dizer que será legível para todos.

Claro que o ideal é termos o máximo de legibilidade sempre mas isso não é necessariamente uma obrigação nas DSLs.

lqueiroz: Uma DSL pode ser utilizada para abstrair as regras de negócio de uma linguagem específica através de metadados, interpretadores e geração de algum tipo de artefato. Qual o seu sentimento sobre essa abordagem?

pcalcado: Esta abordagem é difundida pela Microsoft sob o nome de Software Factories, alem de alguns outros fornecedores com produtos mais antigos nessa linha. Eu considero a idéia que motiva tudo muito boa, mas não creio que esteja pronta para ser vendida como um produto de prateleira. As técnicas de transformação automatizada de modelo, como DSL Tools e MDA, ainda precisam passar por alguns passos importantes para que entendamos quando e como utiliza-las.

lqueiroz: As ferramentas de MDA que usam diagramas UML (ou de outro tipo que contenha notações que descrevam os comportamentos dos objetos) podem ser consideradas Graphical DSLs Tools?

pcalcado: Sim e não. Ferramentas de MDA em si trabalham com metamodelos em UML, uma GPL, por isso não são usuárias da técnica de DSLs. Entretanto -sem cair na polêmica sobre se UML serve para fazer este tipo de coisa- alguns fornecedores de MDA juram que você pode colocar uma DSL no topo da UML ou até como seu substituto. Eu nunca vi isso acontecer, nem em pratica nem em teoria, então não posso falar muito sobre este assunto.

lqueiroz: Existem diversas ferramentas que implementam DSLs gráficas como alternativa (às vezes a única forma) a uma declaração textual. A diferença básica entre as duas formas, textual e gráfica, é a forma como os conceitos do domínio são mapeados – utilizando wrappers/idiomas ou elementos visuais. Você concorda que o escopo dessas DSLs gráficas está sendo limitado ao uso em IDEs?

pcalcado: Uma DSL não tem obrigação de ser abrangente ou de não estar vinculada a uma ferramenta. O fato da IDE XYZ definir sua própria linguagem gráfica não é um problema do ponto de vista de engenharia de DSLs. Pode ser um problema para quem for comprar a ferramenta e ficar preso a ela mas de engenharia não é.

O problema que estas ferramentas geralmente trazem é que elas, como descreve Joel Spolsky, possuem abstrações com muitos vazamentos. Você não consegue se livrar completamente do código em função de um assistente gráfico, sempre vai precisar editar texto. Quando se está ciente disso e a ferramenta é utilizada apenas para produtividade os benefícios podem ser maiores que os problemas, mas geralmente essas coisas são vendidas como “a ferramenta que vai substituir todo o seu time de programadores e vai acabar com a escrita de linhas de código” e aí muitas empresas perdem dinheiro e muitos projetos falham.

lqueiroz: Além do Fragmental.tw quais as outras fontes de informação sobre o tema você recomendaria?

pcalcado: Existem algumas fontes excelentes mas são poucas. Martin Fowler está publicando um livro sobre o assunto e disponibiliza seu rascunho gratuitamente. Eu tenho pontos de discordância com o Fowler mas ainda considero a referência mais atual. Existem dezenas de papers na internet publicados desde os anos 70 sobre o assunto, a maioria trabalha questões muito relevantes ainda hoje. Para encontrar outras fontes eu criei alguns filtros no Google para me avisar todas as vezes que algo com o termo DSL é indexado, tem sido bastante útil. Algumas leituras sobre Lisp e Scheme são fundamentais porque muitos textos descrevem os conceitos usando essas linguagens.

No geral para um conceito que ainda está sendo estudado o melhor é escrever bastante, brincar com DSLs que não fazem nada ou até mesmo que são úteis, e ler como as DSLs atuais são implementadas.

Phillip, muito obrigado pela participação e pelos esclarecimentos. Até o próximo post.

Referências:

Fragmental.tw

Fragmental.com.br

Martin Fowler

Evite o uso excessivo de DataSets

Nos últimos meses tenho tido a oportunidade de participar de alguns projetos com a plataforma .NET de forma mais intensa. O que me chamou atenção quando observei o design de algumas dessas soluções foi o uso exagerado de DataSets, o que incide em diversos problemas que comprometem tanto a performance quanto a flexibilidade.

Antes de qualquer coisa, é importante admitir que o DataSet é um mecanismo de manipulação de dados com diversas funcionalidades e que ocupa um importante papel dentro do ADO.NET. Porém, devemos analisar com cautela os casos onde devemos utilizá-lo.

Usar um DataSet em todas as situações onde você precisa manter algo em memória não é, nem de longe, uma boa prática. Se você pretende desenvolver uma aplicação OO, separando de forma coerente as suas camadas, dificilmente terá um DataSet em outra camada que não seja a responsável pela persistência.

Lembre-se de que o DataSet é, em última análise, um conjunto de dados desconectado. Uma cópia em memória das principais características da fonte de dados. Dessa forma, manipular os registros de um DataSet ao invés de objetos de negócio no cliente tem um forte sabor procedural e uma tendência à repetição de código. É altamente considerável evitar isto!

Desempenho. Você já parou para pensar que na maioria dos casos você não precisaria de um DataSet? O fato de o DataReader ser um cursor forward-only (não mantendo os registros em memória) o torna mais performático que o DataSet. Levando-se em consideração que numa aplicação OO, de uma forma geral, você apenas usa o DataSet para recuperar o estado dos seus objetos, substituí-lo por um DataReader aumentará consideravelmente a performance da aplicação.

Estes e outros motivos nos mostram mais um caso de utilização equivocada de um recurso. O problema não é o DataSet (muito pelo contrário), mas sim o desconhecimento ou uma interpretação errada das motivações e intenções do componente. Enfim, aí estão minhas considerações pessoais sobre o uso de DataSet em aplicações ASP.NET. Veja as referências abaixo e tire suas próprias conclusões!

Referências

http://aspnet.4guysfromrolla.com/articles/050405-1.aspx
http://www.simple-talk.com/dotnet/.net-framework/should-you-use-ado.net-datareader-or-dataset/

Dicas para Certificação SAP Netweaver focus Java

Semana difícil,… intervalo grande desde o último post. Contudo, tenho o intuito de manter este espaço com conteúdos bacanas e úteis (!), e prepará-los ou simplesmente escreve-los leva tempo! (tempo que nos falta às vezes🙂 )

Vamos ao que interessa! Depois de ter participado do T3 (train the trainer) de SAP NetWeaver em Recife este ano e de ter feito a certificação, gostaria de deixar algumas dicas para quem está se preparando para fazer o exame.

O mais interessante de todo esse processo foi a desmistificação da plataforma SAP e saber que podemos aproveitar nossas experiências JEE com o SAP Netweaver minimizando consideravelmente as dificuldades na aprendizagem.

Antes de qualquer coisa, é importante afirmar que as principais fontes de informação sobre os tópicos explorados no exame são – adivinha? – os treinamentos e conteúdos disponíveis nos portais SAP. A prova é bastante clara, objetiva e difícil (!), então esteja preparado. Vale observar estas dicas que separei pelos tópicos da prova:

  • J2EE

Segundo maior tópico em número de perguntas. Nenhuma surpresa, aqui é o bom e velho J2EE que conhecemos. Se você já prestou os exames SCWCD e/ou SCBCD ou tem conhecimentos equivalentes, não sentirá dificuldades.

 

Entretanto uma boa revisada em Servlets/JSPs e EJBs – principalmente no ciclo de vida e nas interfaces para acesso local, remoto ou ambos – é essencial e garantir uma boa pontuação neste tópico lhe ajudará a passar na prova.

  • Open Integration

Este tópico é um mix de questões sobre temas específicos de tecnologias SAP e temas já conhecidos. A grande sacada em relação a estes temas independentes da SAP é identificar as diferenças de implementação e as nomenclaturas usadas principalmente no SAP NetWeaver Developer Studio.

 

Quanto aos temas mais específicos, procure dar uma atenção especial ao SAP Enterprise Connector (JCo), e a comunicação Java->R/3 e R/3->Java. Questões sobre Web Services certamente aparecerão…

  • J2EE Persistence

Este tópico, em geral, tem o mesmo número de questões que o anterior. Nesta parte da prova um entendimento sobre OpenSQL e operações básicas com SQLJ são suficientes. Os quesitos mais explorados dentro deste tópico foram SQLJ e os Entity Beans.

  • Java Development Infrastructure

Chegamos ao primeiro tópico totalmente específico SAP. Porém, não precisa temê-lo. Este tópico aborda um conjunto de procedimentos e tecnologias – utilizados no “mundo ABAP” e que foram migrados para o “mundo Java” – que são aplicadas em diversos momentos no ciclo de vida do software. Ex.: modelar, versionar e distribuir os componentes que compõem um produto.

 

Não são temas complicados, muito pelo contrário, só exigem uma vivência em desenvolvimento de software em equipe. Sendo assim, a principal dica para esta parte da prova é decorar as siglas dos componentes (como: DTR, CBS, CMS e etc.) e entender o papel de cada um dentro do NWDI.

  • Web Dynpro

Chegamos ao temido Web Dynpro! O maior tópico em número de perguntas. Infelizmente, para esta parte da prova a única dica é estudar bastante, ficar atento às convenções e a estrutra dos componentes Web Dynpro e, se possível, praticar muito! A maioria das questões deste tópico são sobre Dynamic Programming, Hook Methods (callbacks) e os papéis do MVC abordados num componente Web Dynpo.

 

Fiquem atentos também as diferenças entre componentes visuais e não-visuais, e os elementos básicos de todo componente Web Dynpro.

 

Pronto. Estas são as minhas considerações sobre os tópicos do exame. Outra coisa que gostaria de ressaltar é o estilo das respostas. Todas as perguntas têm no mínimo 4 respostas e, diferente do estilo Prometric, o enunciado não informa o número de questões corretas. Todas as respostas têm dois radiobuttons que indicam True/False. Você precisa informar corretamente True ou False para todas as respostas da pergunta, o que eleva o grau de dificuldade da prova.

Espero ter ajudado. Boa sorte a todos!

Referências:

Detalhes Exame – https://websmp101.sap-ag.de/~sapidp/011000358700003595742004E
SDN –
https://www.sdn.sap.com/
Help SAP –
http://help.sap.com/

Você usa DTO/TO/VO em aplicações não distribuídas ?

Esta semana eu estava discutindo com alguns colegas de trabalho, sobre a arquitetura de alguns sistemas J2EE que tínhamos (o desprazer) de manter. Até certo momento estávamos concordando em todos os pontos fracos da abordagem utilizada nestes sistemas. Quando de repente um deles me surpreende com: “Um projeto J2EE bem feito, pra mim, tem que ter no mínimo…”. Começou então a discussão:

Colega A: Um projeto J2EE bem feito, para mim, tem que haver no mínimo um Façade, tem que ter DAOs e … DTOs.

Eu: DTOs? Depende…

Colega A: Como assim depende? Um projeto sem DTO?

Eu: Sim, sem DTO! Não há motivo para utilizarmos um DTO (Na verdade falávamos de Transfer Objects) na maioria das aplicações que desenvolvemos.

Colega B: Eu devo ou não usar DTOs,… TOs,… (arrg!) isso aí que vcs estão falando?

Colega B: Decidam-se…

Colega A: Ele deve ter visto isso em algum lugar e acha que pode escrever uma aplicação J2EE sem usar um DTO. Neste momento eu percebi que meu colega não havia gostado muito da idéia de ter seu modelo de arquitetura questionado. Vamos seguindo…

Eu: Alto lá! Eu sei para que servem os Transfer Objects e uma aplicação web onde as camadas residem na mesma JVM (a maioria dos projetos) não é um caso onde devemos implementá-los. Acompanhe meu raciocínio: A intenção do padrão Transfer Object é transferir dados entre tiers (e não layers) visando reduzir os custos das chamadas remotas num cenário distribuído. Logo, nossa aplicação não precisa de TOs!

Colega B
: hmmmm

Colega A
: Tudo bem, mas então como iremos mapear as entidades do banco? O Hibernate precisa de objetos para serem mapeados… e aí? Cara,… eu aprendi e sempre trabalhei criando uma classe que é um espelho de uma tabela do banco (TO) e uma classe contendo as regras de negócio, as validações (BO).

Eu: Sim, concordo com você! O Hibernate precisa de objetos, e objetos “de verdade” têm dados + comportamento. Ao criar a dupla ClienteTO + ClienteBO você está dividindo o domínio (objeto) Cliente em duas classes desnecessariamente. Veja a definição de um Acemic Domain Model do Matin Fowler.

Você trabalha com os TO como se fossem registros de uma tabela (um resultSet) as regras de negócio e as validações você escreve no BO (Business Object) e repete onde quer que você precise tratar dados do seu TO. Isso é programação estruturada, não é OOP! Eu não sei o porquê, mas entendo que este não seja um pensamento só seu. Já vi diversos profissionais programarem dessa forma (por uma interpretação errada dos padrões, ou muitas vezes obrigados a seguir uma arquitetura de referência adotada em sua empresa), eu mesmo já programei assim!

Colega A: É verdade…

Eu: Já li diversos textos e discussões em fóruns onde algumas pessoas ainda tentam, mas sem sucesso, justificar o uso de TO numa aplicação não distribuída. É a febre dos patterns! Às vezes você cria situações para justificar a injeção (palavra na moda 🙂 ) de um pattern em seu design? Evite isso.

Colega A: Sim,… e o que vc passa para sua camada de apresentação? Se não tenho mais DTOs eu vou passar os objetos de domínio?

Eu: Sim! Você tem algum bom motivo para não passar os “BOs” ? Se for por questões de acoplamento, observe que um diagrama com TOs é mais complexo e tem mais acoplamento do que uma versão sem TOs. Se a questão é proteção de alguns dados e/ou métodos, se você programou sua View para interfaces e não para classes concretas, pode usar interfaces de negócio mais restritivas em relação à API do seu componente expondo somente o necessário (Lembrei das Virtual Interfaces de Web Services do SAP NW🙂 ).

ComSemTransferObject

Os colegas citados acima existem (!) e foram convidados a comentar este post, veremos se eles continuam pensando da mesma forma🙂 …

Fontes sobre o assunto:
Martin Fowler, http://www.martinfowler.com
J2EE AntiPatterns
Phillip Calçado “Shoes” (ThoughtWorks), http://fragmental.com.br/wiki/index.php?title=Fantoches
Discussão no GUJ: http://www.guj.com.br/posts/list/28889.java