Categories
Domain-Driven Design Engenharia de software Eventos

[QCon 2007] Eric Evans: Domanin-Driven Design

Qcon 2007 - Eric Evans - Domain-Driven DesignA apresentação do Eric Evans hoje sobre Domain-Driven Design foi excelente! A abertura do evento não poderia ter sido melhor!

Grande parte do que ele apresentou faz parte do seu livro sobre DDD, incluindo alguns dos exemplos usados no tutorial. Mas isso não fez com que as coisas ficassem menos interessantes. Muito pelo contrário, as discussões foram excelentes.

Falamos inicialmente sobre as características de um bom design de domínio. Na opinião do Eric um bom design é aquele que você consegue explicar para uma pessoa qualquer e ela entende mesmo não sendo especialista no negócio/domínio. Sobre codificação, o Eric falou que se interessa bastante pela clareza trazida por Fluent Interfaces, e DSLs internas e tenta usá-las sempre que possível pois aumenta muito a legibilidade do código. Além disso ele acredita que o uso de Behaviour-Driven Development é interessante no processo exploratório de um domínio e pode te ajudar a identificar e corrigir problemas de design.

Uma das frases que o Eric falou me lembrou a discussão que rolou na semana passada no GUJ sobre testes, TDD e etc: “Estamos no ano do Test-Driven Development e criar designs testáveis é essencial!”. Não quero acender novamente a discussão mas não posso deixar de dar a minha opinião nessa história. Realmente é inaceitável um software nos dias de hoje não ter uma suite de testes decente, não só pelos testes em sí mas por toda a influência positiva que isso traz no design do código, pela segurança que te dá para incluir novas funcionalidades e modificar existentes, segurança para corrigir bugs e tudo mais. Para mim é simplesmente impossível programar sem testes!

Guilherme Chapiewski e Eric EvansInfelizmente não consegui todo o material do curso porque o Eric utiliza esses materiais nos seus treinamentos e por isso não os disponibiliza publicamente. Mas eu consegui o Domain-Driven Design Pattern Summaries, que é um resumo de 39 páginas do livro dele com algumas coisas a mais. Achei bem interessante para se usar como referência. Esse resumo contém informações bem objetivas sobre todos os padrões apresentados no livro de DDD.

Além desse material o InfoQ disponibilizou a palestra Putting The Model To Work que foi uma das que o Eric apresentou para nós. Essa não foi exatamente a apresentação que tivemos mas foi bem parecida.

Para os leitores assíduos de blog, aí vai uma boa notícia: num dos intervalos eu perguntei para o Eric porque que ele não tinha um blog. Ele disse que ultimamente muitas pessoas têm feito essa pergunta e disse que está preparando alguma coisa nesse sentido. Perguntei sobre quando ele planeja lançar isso e ele disse que seria em breve! Com certeza será mais uma ótima fonte para leituras.

E para terminar, a gafe do dia: na hora do intervalo subitamente começamos a ouvir na sala vários barulhos estranhos de mictório e pia de banheiro… O Eric deu bobeira e foi no banheiro com o microfone sem fio ligado! Ao menos constatamos que o microfone era de boa qualidade porque o banheiro era meio longe, haha!

Categories
Agile Engenharia de software XP

Para que você vai usar isso?

Quando você se reune com seus usuários para definir um sistema é muito comum que alguém apareça com requisitos que não fazem o menor sentido e que não agregam o menor valor para o software.

Uma vez fazendo levantamento para o desenvolvimento de um sistema alguém me pediu para mostrar em algum lugar da tela a quantidade de pessoas logadas. Tá, eu confesso que era uma coisa relativamente simples de ser feita. O que acontece é que no meio de tantas coisas realmente importantes fazer aquilo me parecia completamente estúpido e inútil.

Então, tentando espremer o usuário, fiz aquela pergunta clássica: “e para que você vai usar isso?”. Normalmente o cara responde alguma coisa vazia como: “eu preciso saber quantas pessoas tem logadas no sistema para ver se tem um número bom de pessoas trabalhando”. E você fica sem saber o que responder e acaba aceitando.

Segundo Scott Bellware, uma forma eficiente de resolver este problema é perguntar para o usuário da forma correta. Ele escreveu um post no Code Better sobre como utilizar uma abordagem de behaviour-driven development para discutir funcionalidades de um sistema.

Neste caso, eu poderia ter perguntado para o usuário: “você poderia me descrever uma história com este requisito?”. Desta forma eu faria com que o usuário percebesse que nenhuma situação de uso real do sistema iria requerer que tal funcionalidade existisse. Na verdade este é o benefício principal de Behaviour-Driven Development. A idéia é que pensando na forma como o software irá se comportar você consegue perceber com mais clareza qual é o comportamento realmente necessário e não o que você imagina que seja necessário.

Desenvolver um sistema a partir de um comportamento necessário faz com que você desenvolva software que atende aos usuários. Já desenvolver um sistema a partir um dado que deverá ser apresentado pode fazer com que você desenvolva software inútil sem se preocupar ou entender o que realmente importa.

Parte da nossa missão trabalhando com desenvolvimento de software é guiar o usuário e fazê-lo entender o que ele realmente precisa, não o que ele acha que quer ou acha que precisa.

Categories
Comunidade Refactoring TDD XP

Slides da palestra sobre TDD no RioJUG

Estou disponibilizando os slides da palestra sobre Desenvolvimento Guiado por Testes apresentada no RioJUG no dia 19/06/2007.

Desenvolvimento Guiado Por Testes

View SlideShare presentation or Upload your own. (tags: tdd bdd)

Como o tempo ficou curto lá na palestra acabei não apresentando o último slide que contém alguns links interessantes para quem quiser conhecer mais sobre o assunto: