Segue uma seqüência aleatória quase coesa de pensamentos que me vieram a cabeça enquanto esperava meu vôo para Salvador.
Paulo Silveira surgiu com o termo BOLOVO, usado para indicar uma arquitetura baseada em VOs e BOs, enquanto preparávamos os slides para nossa apresentação em conjunto no JustJava em 2007.
O artigo original sobre BOs e VOs fala basicamente sobre como a arquitetura proposta por EJBs na especificação antiga (2.x) prejudicou o entendimento da comunidade em geral sobre como criar a aquitetura de uma aplicação.
Três anos se passaram mas o artigo ainda recebe um numero de acessos razoável –e eu vivo prometendo que vou atualizá-lo. A última vez que tive que escrever um EJB 2.x foi em 2007, desde então –talvez por sorte- nunca mais entrei em um projeto que usasse estas aberrações. Muitos programadores de hoje em dia começaram suas carreiras na época que EJB já estava morrendo e nunca tiveram o desprazer de lidar com esta porcaria. É de se esperar que estas pessoas, tendo estado sempre cercado por IoC, DDD e técnicas bem razoáveis, iria olhar para um artigo como o que escrevi da mesma forma que eu olho para um livro de linguagem de máquina para Apple II –interessante no contexto histórico mas quase que apenas uma curiosidade.
Vira e mexe, entretanto, eu sou lembrado do porque o artigo ainda recebe tantas visitas todo dia. Os programadores mais novos podem não ter sido influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.
Quando estava preparando a primeira iteração do workshop de Domain-Driven Design que faço em parceria com a Caelum eu escrevi um texto para explicitar meu raciocínio sobre como Domain-Driven Design se difere de Orientação a Objetos. No workshop em si eu dediquei boa parte da manhã falando sobre este tema.
E por quê? Porque da mesma maneira que as pessoas utilizavam os conceitos de EJB completamente fora de contexto o mesmo está acontecendo com Domain-Driven Design. É bem comum, em uma conferencia ou algo do tipo, alguém vir conversar comigo sobre como a empresa dele está eliminando todos os BOs e VOs. No meio da conversa a pessoa começa a me explicar a arquitetura e eu vejo que praticamente o que eles fizeram foi renomear UsuarioBO para UsuarioService e UsuarioVO para Usuario. Repositórios, então… estes são tão mal utilizados que deram origem à vários textos aqui:
- http://blog.fragmental.com.br/2007/03/01/voce-pergunta-001-daos-e-repositorios/
- http://blog.fragmental.com.br/2007/06/05/dao-e-repository/
- http://blog.fragmental.com.br/2008/05/22/domain-driven-design-e-simples/
- http://fragmental.tw/2008/04/25/repeat-after-me-repositories-arent-daos/
- http://fragmental.tw/2007/11/29/repositories-misunderstandings/
- http://fragmental.tw/2007/09/05/rounded-tip-scissors/
Independente do uso de DDD e seus padrões ou não eu realmente esperaria que, em 2010, as pessoas já houvessem entendido como objetos deveriam ser criados. A quantidade de material disponível gratuitamente na Internet e em múltiplos idiomas é ridiculamente grande.
Me levou muito tempo para entender que não importa a quantidade de material disponível. Em minha experiência, a maneira mais eficiente de introduzir estes conceitos é programação em par. Quando um cliente me chama para introduzir estes conceitos em seu time eu sempre tenho que tentar explicar porque isso não pode ser apenas um treinamento. Ë difícil de entender porque eu posso treinar alguém em algo complexo como uma linguagem de programação mas não em uma técnica com mais de 40 anos que exige como pré-requisito nada mais que conceitos lógicos básicos. Eu, pessoalmente, não faço a menor idéia do porque as coisas são assim, só sei que o são.
Normalmente eu começo o trabalho com uma apresentação rápida, apenas para tentar fazer as pessoas entenderem o que diabos eu vou tentar fazer. Um exemplo de uma destas apresentações:
E logo depois começamos a parear. O ideal é termos pelo menos 1 coach para cada dois pares, mas nem sempre este número é viável. Quando a quantidade de pessoas exceed muito a quantidade de coachs a melhor solução parece ser pareamento promíscuo, mudando os pares em intervalos bem curtos de tempo.
Nestes últimos anos eu tive diversas oportunidades de reencontrar clientes e parceiros depois da conclusão do projeto ou treinamento. Na minha experiência os times que tiveram apenas treinamento retêm apenas uma ou outra coisa do todo, eles entendem o todo mas não conseguem aplicar na prática –e aí mora o perigo do Domain-Driven BOLOVO. Os times onde utilizei coaching como meio de transmissão de conhecimento tendem a ser o contrario: eles usam as técnicas no dia-a-dia mas não entendem o todo. Ao não entender o todo eles não conseguem evoluir alem do que o que lhes foi passado durante aquele período.
É de se esperar que o primeiro grupo seja mais valioso para um empregador. Na prática, entretanto, não parece ser o caso. Um treinamento, um livro, etc. podem curar a deficiência do segundo grupo e tendem a ser bem mais baratos e eficientes que gastar dinheiro com um consultor que cobra por hora. O grande benefício que o consultor vai te trazer é que ele sabe –ou deveria- como utilizar aqueles conceitos na prática. O melhor uso do consultor neste caso é trabalhar com o time no dia-a-dia e realizar pequenas sessões de treinamento –no meu caso geralmente isso significa 20 minutos por semana- conforme necessário.
