QuantoEh: Vamos do começo

Tempo de leitura:6 minuto(s)

Se você não sabe ainda o que é o projeto “Quanto é”, leia isso aqui primeiro.

Quanto é?Muita gente se empolgou com o projeto QuantoEh, e minha ideia é trazer para cá um pouco de como ele surgiu e explicar ele tecnicamente.

Esse post é o primeiro de uma série, que não sei ainda quantos posts vai ter. O QuantoEh usa Azure, Boo, TPL, LINQ to Twitter, DDD, BDD e vários outros conceitos e tecnologias, e a ideia é explicar pelo menos um por post.

Neste post vou abordar a modelagem inicial do sistema, que sem dúvida foi algo que demorou a sair.

O projeto iniciou no TechEd 2010. É comum que o pessoal do .Net Architects se reuna para fazer algum projetinho durante os eventos de tecnologia, e a ideia surgiu de novo. O Felipe Rodrigues estava junto e se animou também. A ideia era fazer algo com Azure, já que o TechEd estava propondo isso. Queríamos terminar até o segundo dia do evento. Olhando pra trás eu dou risada, não tínhamos ideia do tamanho do desafio.

O Vinicius Quaiato trouxe a ideia de fazer uma “calculadora social”, que é o que o QuantoEh virou. Até aí, tudo muito fácil. O difícil começou quando sentamos para definir como seria o aplicativo.

O Felipe e eu somos conhecidos por falar frequentemente sobre DDD, ele, inclusive, a mais tempo do que eu. Quem é da comunidade Microsoft não o conhece tanto, mas no lado de Java ele já trazia o assunto há um bom tempo. Naturalmente o sistema seguiria por esse caminho. Como o foco era aprender, nada como pegar um sistema essencialmente não visual (não tem interface gráfica) e aplicar um conceito de DDD para ver como ele funcionaria. (Se você não sabe o que é DDD, veja este vídeo com uma palestra que ministrei ao .Net Architects em 2008).

E foi um desafio. Como bons agilistas, começamos com as especificações, usando StoryQ. Depois eu volto a falar do StoryQ, que vai merecer um post só pra ele, nesse momento vou focar no DDD. Tentamos escrever algumas especificações, tínhamos dois pares para iniciar no código. Aí começou o problema. Não concordávamos nas histórias, não concordávamos no modelo, não concordávamos nos limites do domínio. O Felipe e eu gastamos as 4 últimas horas do TechEd discutindo isso, e não concluímos.

Só fomos concluir no RubyConf, onde continuamos o projeto, cerca de um mês depois, com ajuda do Felipe e do VInicius. Aí o projeto evoluiu, eu segui com ele no Google Developer Day, onde o Felipe deu uns pitacos, e eu terminei ele em casa porque eu não aguentava mais ver ele pela metade.

Qual foi a dificuldade? A principal foi a fronteira do domínio. Tínhamos algumas entidades identificadas, como o tweet recebido e que seria processado, e o retweet para enviar. Eles são objetos de domínio. Mas haviam vários outros objetos que não tinham papel definido. E essa discussão nos tomou muito tempo.

Domínio?

Nos parecia claro que o WorkerRole do Azure estaria na camada de interface com o usuário, ainda que essa interface não fosse gráfica. A fila de cálculo e a fila de retweet nos pareciam repositórios, mas isso não estava claro. E o timeline e as menções do twitter, onde postaríamos as respostas e obteríamos os tweets que mencionavam o quantoeh pareciam repositórios também, mas isso não estava claro. Definir este papeis era muito importante, porque influenciaria nossas especificações, nossa arquitetura e nosso design. Paramos de escrever qualquer especificação com BDD até termos isso definido. E foi essa discussão que levou algumas horas, e evoluiu muito nosso conhecimento do negócio e sobre como modelar tudo de maneira que fizesse sentido.

Um breakthrough aconteceu quando descobrimos que, na verdade, o timeline e as menções não eram repositórios, mas parte da camada de interface com o usuário. Eles pareciam repositórios porque era através deles que chegavam e saiam os tweets, e repositórios tem essa característica de obter e guardar objetos de domínio. Mas, na prática, não era isso que nosso domínio nos apresentava. Os tweets chegavam de uma fonte externa para serem processados, eles estão fora da aplicação. Sua entrada na aplicação se dá de forma muito semelhante ao input feito por um usuário via interface gráfica, se esse fosse um sistema que tivesse telas de input. Quando ficou evidente que as menções eram um componente da camada de interface com o usuário, nossas especificações começaram a mudar. Da mesma forma, descobrimos que a timeline se comportava de forma muito parecida. É como se ela fosse a tela que mostra o resultado do cálculo, só que ela faz isso pela interface do twitter, não da nossa aplicação. Ela representa uma saída para o usuário, não um repositório onde salvamos tweets processados. Ter percebido isso facilitou muito nossa visão.

As filas de cálculo, ficou evidente depois, são repositórios. Vou voltar nelas, mas em um post futuro.

Neste post meu objetivo é deixar claro que pensar sobre o domínio é fundamental antes de escrever especificações, sejam com código ou com papel. O QuantoEh evidenciou que nem tudo que salva ou obtém dados é um repositório como muitas pessoas pensam. O mais interessante é que a timeline e o as menções depois foram implementadas por um data access object (DAO), e são componentes de interface com o usuário, contrariando o que muitas pessoas entenderiam como o correto. Você pode ver a última versão do código do DAOTwitter no BitBucket.

Eu sempre digo que DDD não é entidades + repositórios, que não é uma nova forma de pensar em forms over data. O QuantoEh confirmou isso nas primeiras horas do projeto.

Nos próximos posts eu sigo discutindo arquitetura e já devo entrar nas especificações com BDD. Até lá.

Autor: Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador.
Programa porque gosta, e começou a trabalhar com isso porque acha que trabalhar como administrador é meio chato. Por esse motivo sempre diz que nunca mais vai virar gerente de ninguém. E também porque acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é melhor que hierarquia. Mas isso é outro assunto.
Foi reconhecido  Microsoft MVP depois que alguém notou que ele não dormia a noite pra ficar escrevendo artigos, cuidando e participando do .Net Architects, gravando o podcast Tecnoretórica, escrevendo posts no blog e falando o que bem entende no twitter @giovannibassi. E por falar nisso é no twitter que conta pra todos que gerencia de projetos deve ser feita pelo time e não por um gerentes, que greves em TI são coisas sem sentido e que stored procedure com regras de negócio são malígnas.
Você já deve ter percebido (até porque está lá na primeira frase) que Giovanni é agilista. De tanto gostar disso ele trouxe os programas de certificação e treinamento  PSD e PSM da Scrum.org pro Brasil, e por causa deles, do MVP e de algum trabalho que aparece tem que ficar indo pros EUA de vez enquando, coisa que prefere não fazer. (É bem comum você ouvir ele perguntando porque a Scrum.org e a Microsoft não estão na Itália, por exemplo.)
Junto com alguns Jedis criou a Lambda3, que, apesar de ser pequena e de não ser muito comum no Brasil, insiste em fazer projetos e consultoria direito. Por causa da Lambda3 ele tem trabalhado mais do que quando era consultor independente, mas menos do que a maioria das pessoas. Quer dizer, isso se você considerar que os trabalhos junto à comunidade não são trabalho, caso contrário ele trabalha mais que a maioria das pessoas.
Recentemente ele resolveu que merecia viver melhor e ganhar uns anos de vida e desistiu de ser sedentário, fazendo algum barulho de vez em quando com os amigos no twitter com a hashtag #DotNetEmForma. Por causa do convite recente de amigos do lado Open Source (que ele respeita e admira), começou a escalar, e agora está sempre com as mãos machucadas. Mas ainda dá pra programar. Você encontra ele sempre em algum evento, como o TechEd, e o DNAD, mas também outros menos comuns para o pessoal do .NET, como a RubyConf. Nesses eventos, ou ele está vendo palestras, ou batendo papo com alguém, ou codando alguma aplicação que alguém achou que dava pra fazer durante o evento.

  • Não entendi a parte que os tweets são lidos. É um serviço que fica lendo de tempo em tempo?

  • Vinicius Quaiato

    Pois é… a comunidade precisa ler muito o livro do Evans para compreender as coisas. Implementar o pattern Repository está longe, há anos luz, de ser DDD. Colocar um Id em um objeto está longe de ser uma identidade que o define como Entidade. É preciso estudar, e mais, conversar e confrontar pessoas com esse conhecimento.
    O QuantoEh parece despretencioso, e discutir 4 ou 6 horas é algo razoável, ao contrário teríamos 4 ou 6 horas de trabalho inútil!
    Fazer software não é apenas escrever linhas de código, é compreender conceito, escavar e compreender o software que se faz, caso contrário, seriam necessários apenas digitadores.

    Abraços Giggio,
    Vinicius Quaiato – QuantoEh core member 😛

  • Pingback: QuantoEh: Vamos do começo | Blog Lambda3()

  • Pingback: QuantoEh: Vamos do começo()

  • Cara demais!
    Ilustra exatamente que desenvolver software CORRETAMENTE não é um trabalho fácil.
    Exige muita paixão, talento, raciocínio e dedicação!