Durante a fase de design e desenvolvimento de software é natural seguirmos uma ordem de etapas. O mais comum, que muitos aprendem na faculdade e praticam no dia-a-dia é:
- definir o modelo de dados
- construir a camada de negócios
- criar a interface do sistema
A lógica por trás desta ordem é que a camada de dados deve ser a mais consistente e menos mutável do sistema. O custo de alterar o banco de dados é alto e existe risco de perda de dados. Em seguida é criada a camada de negócios e por último a interface com o usuário, pois esta é mais suscetível a mudanças e é “apenas” uma apresentação dos dados, que pode ser mudada rapidamente.
Eu tive um professor de modelagem de dados que fazia lavagem cerebral nos alunos convencendo todos de que a modelagem de dados era o passo mais importante e, portanto deveria ser o primeiro durante o projeto. Acho que todo professor de modelagem de dados é assim.
Agora vou “sair da caixa” e inverter a ordem das coisas. Se a camada de dados é mais difícil de se modificar seria melhor se eu pudesse postergar ao máximo a definição do modelo de dados. A cada dia que passa no projeto ganhamos um pouco mais de conhecimento para modelar melhor. Não quer que você irá atrasar a etapa e ficar a vida toda “fazendo carinho” no modelo de dados, muito pelo contrário. A idéia é desenvolver a camada de negócios e amadurecer o modelo de dados no processo.
Um dos princípios do Lean Software Development é: Decide as late as possible. Em uma realidade incerta atrasar decisões é interessante pois quanto mais informação melhor será sua decisão. Deixar opções em aberto, como por exemplo qual ferramenta de integração ou qual camada de persistência será utilizada, também deixa a arquitetura mais aberta a mudanças. Um benefício extra.
Para fazer isto é necessário isolar muito bem as camadas e utilizar técnicas de teste unitário e mocking para ser capaz de evoluir no desenvolvimento da camada de negócios, substituindo a camada de dados por uma camada provisória durante o processo. O Domain Driven Design Quickly, de Eric Evans, mostra alguns patterns interessantes para isto.
E a UI? Onde ela ficou? No livro Getting Real, o pessoal da 37 signals sugere que a UI deve ser desenvolvida antes de qualquer coisa. Segundo eles o custo de mudar a UI em tempo de protótipo é baixo, além disto é prático para discussões com usuários e clientes.
Outra alternativa é desenvolver a UI em paralelo com a camada de negócios, funcionalidade a funcionalidade. O importante, neste caso, é ter mente o princípio do Agile Manifesto: Deliver working software frequently. Desta forma a resposta do cliente/usuário é mais rápida e mais fácil fica absorver as mudanças necessárias.