Continuando a serie sobre o Domain Driven Design iniciada aqui, vamos agora comentar sobre como arquitetar as camadas da aplicacao de modo a utilizar um Domain Model rico como a "base" do desenvolvimento.Antes de mais nada, convem salientar que essa nao deve ser vista como a unica arquitetura que existe e que ira atender a todos os sistemas e situacoes do mercado. Trata-se apenas da arquitetura mais adequada a um projeto que trabalhe sob as premissas do DDD.As camadas sao representadas como abaixo: Explicacao sobre as camadas:E importante dizer que nao considero a camada Application como mandatoria; ela e criada apenas se realmente adicionar valor a aplicacao. Como a camada Domain e bastante rica em funcionalidades, muitas vezes nao e necessario implementar mais essa divisao. A criacao de um Domain Model traz uma serie de vantagens para aplicacoes de larga escala e/ou complexas. Como bem disse Martin Fowler em PoEAA: "se voce utilizar DDD para um projeto, voce provavelmente ira cogitar utilizar a mesma tecnica para outros (mesmo para os pequenos)."Um design focado na criacao de um Domain Model tem melhor manutencao no longo prazo devido a clareza da relacao entre o negocio e a implementacao. Alem disso, e uma importante ferramenta para evitar a duplicacao de codigo. Tambem aumenta a testabilidade do sistema. Fala Pessoal,Tudo bem? Estarei fazendo uma oficina na Rio Info 2010, junto com meu amigo e mestre Armenio Cardoso, nessa proxima quarta-feira, dia 01/09/2010. Vamos abordar a construcao de um aplicativo Java Mobile utilizando o Agile como pano de fundo.Quem quiser ir na oficina me avise aqui no blog (ou por email) que eu envio a senha para efetivar o convite. Temos um limite de convidados que podemos chamar.Cliquem aqui para saber mais sobre a oficina e sobre a Rio Info 2010.Abracos, Laurie Williams, uma professora da North Carolina State University, vem conduzindo uma pesquisa para descobrir quais as praticas e os principios que sao mais utilizados pelas equipes ageis.A pesquisadora tambem convida os participantes a repensarem os principios e praticas, propondo sugestoes de melhoria (quando aplicavel). Vejam os cinco principios considerados mais importantes ate o momento:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Working software is the primary measure of progress.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.E as cinco praticas mais importantes:Short iterations (30 days or less)Continuous integrationDone criteriaAutomated tests are run with each buildAutomated unit testingVoce pode conferir as atualizacoes da pesquisa aqui.Caso queira participar da pesquisa e so vir aqui. Quais sao os limites para o desenvolvimento agil de software? Essa e, provavelmente, uma pergunta que passa pela cabeca de muitas pessoas (inclusive na minha). Infelizmente, nao ha respostas faceis para essa questao e, para piorar um pouco, ha alguns mal entendidos classicos a respeito do