Ultimamente tenho estudado os autores clássicos de desenvolvimento ágil como Kent Beck, Martin Fowler, Robert C. Martin, etc e sofrido bastante. Tendo revisto meus projetos anteriores vi como minha modelagem se baseava no AnemicDomainModel como citado nesse artigo do Fowler.
Todos meus sistemas se pareciam como uma implementação do catálogo de patterns da SUN como se aquilo fosse uma interface.
Recentemente tive oportunidade de ser o responsável por todo o ciclo de desenvolvimento de um projeto pequeno com poucos requisitos funcionais, tinha ao todo uns 10 casos de usos tirando o aspecto CRUD da aplicação.
Pude realizar algumas experiências com conceitos que eu estava estudando a algum tempo e alguns que eu conhecia mas nunca tivera oportunidade de implementar.
Estou planejando um artigo mais elaborado sobre essa experiência, mas por enquanto posso adiantar alguns sentimentos sobre tudo isso.

Test-Driven Development
Essa prática do XP realmente é muito mais produtivo, eu sempre realizei os testes depois que as classes estavam desenhadas e até com métodos implementados, mas nesse sistema eu simplesmente aboli os diagramas de classes da UML, tentei fazer tudo radicalmente, fui separando as classes que eu achava que existiam no dominio da aplicação com cartões CRC, mas depois abandonei os cartões e fui direto para os “Unit Tests”, outro princípio que segui do XP foi fazer os casos de uso importantes primeiro, CRUD eu nem toquei, o banco de dados foi a última coisa que fiz. Fui criando os Unit Tests (UT) e os objetos foram surgindo naturalmente a partir dos requisitos funcionais que respondiam pela cerne do sistema, quando terminei o modelo praticamente tinha o sistema concluido, apesar de não ter nenhum select implementado. Nesse momento eu não sabia como seria a performance ou se teria que refatorar tudo aquilo para se adequar ao banco mas sentia que a aplicação estava terminada, diferente de todas as vezes onde fiz os CRUDs primeiro (que correspodem por cerca de 80% das aplicações ou mais) e praticamente via um túnel sem fim pela frente.

Domain Model
Meu modelo criou classes que a muito tempo não via (acho que desde os sisteminhas de locadora da faculdade). Minhas classes não são apenas tabelas em memória como repositório de dados, elas conhecem suas responsabilidades e seus dados como descrito nesse pattern do Fowler, acredito que as classes criaram até sentimentos (risos!).
Minha forma de pensar era um Bean que mais parecia uma tabela e que viajava da persistencia até o jsp, furando tudo pelo caminho, então dessa forma pude testar todo o sistema praticamente de minhas classes de testes no JUnit usando refactoring a todo momento e criando um modelo estável e que realmente está testado e terminado. Minhas classes sabem fazer o que tem que ser feito, ou seja, elas tem suas responsabilidades, olha só essa frase:

Procedural code gets information then
makes decisions. Object-oriented code tells
objects to do things.
— Alec Sharp

Acho que já to programando OO!

Design by contracts
Pude implementar os conceitos DbC nesse projeto, aliás quando voce desenvolve criando os testes primeiro isso flui quase que naturalmente, basta uma polida nos conceitos e pronto, um bom lugar para isso é esse artigo do Phillip Calçado sobre o tema.

Futuro
Algumas coisas não puderam ser implementadas como Dependency Injection, Aspect Oriented Programming, Pair Programming, Continuos Integration, etc. Esses conceitos vão ficar para os próximos projetos, pretendo adotar Hibernate e Spring na próxima e ver o que essas boas práticas são capazes, vou primeiro tentar convencer minha equipe a adotar o XP como metodologia, aí veremos, qualquer coisa esses conceitos já me foram uteis, aguardem novidades.