O documento discute arquitetura evolutiva de software, definindo programação como um processo criativo de tomada de decisões, e arquitetura como um conjunto de convenções e decisões iniciais que podem facilitar ou dificultar mudanças futuras. Ele também apresenta as fases de concepção de um produto de autoatendimento, discutindo como a arquitetura deve ser definida para atender o momento do projeto e possibilitar sua evolução.

1. Arquitetura evolutiva

2. http://www.linkedin.com/in/denisferrari

4. Meta da apresentação
• Questionar em qual momento a arquitetura
deve ser pensada e aplicada...

5. O que é programação?

6. (Código é conhecimento registrado)

9. A programação é como uma redação.

10. A programação, assim como a redação...
• Pede por macro-decisões;
• É definida nas micro-decisões;
• Depende de valiação externa;
• Novas implementações necessitam da
avaliação do todo;
• É um processo criativo…

11. (O TDD é fod* legal pois auxilia as micro-decisões)

12. O que é arquitetura de software?

14. (A arquitetura é o universo.
O design é a história)

15. A arquitetura...
• Conjunto de macro-decisões;
• Conjunto de convenções;
• Códigos de base (requisitos não funcionais);
• “Define” como as coisas devem ser feitas;
• Pode facilitar ou atrapalhar novas
implementações;
• É difícil de mudar;

17. Qual o tamanho ideal de um
time de desenvolvimento?

18. Dois programadores, um designer.

19. (A qualidade dos integrantes de um time é mais
importante do que a quantidade de pessoas)

20. (Um projeto de software é como uma
criança, seu comportamento final dependerá
das influências que ele recebeu dos adultos que
estavam perto durante seu crescimento)

21. CONCEPÇÃO DO PRODUTO
Primeira fase

22. Funcionalidades
• Base de conhecimento;
• Gerenciador de avisos;
• Interface de auto-atendimento;
• Busca com relevância*;

23. Tecnologias

24. Uma tecnologia deve estar
alinhada com os conceitos do seu projeto e
não deve definir como você irá trabalhar.

27. (Cuidado com a política nas decisões).

31. (A interface com o usuário
antes da programação)

32. (A utilização do código
antes de sua construção)

33. (Analisar o comportamento do usuário
antes de construir o que você acha importante)

34. PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO

35. Quando a arquitetura de um projeto
deve ser definida?

37. (O livro de DDD não é a bíblia e saber
arquitetura não faz de você um cara mais legal)

38. A arquitetura deve
atender ao momento do projeto e
possibilitar a sua evolução.

39. ESTATÍSTICAS E IMPORTAÇÃO
Segunda fase

40. Funcionalidades
• Ferramenta de importação;
• Informações estatísticas sobre a base de
conhecimento;
• Interação do usuário com a base de
conhecimento;

41. (Migração de dados é uma coisa chata)

44. PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFRAESTRUTURA

45. MULTICLIENTES
Terceira fase

46. Funcionalidades
• Multi-Tenant;
• Separar necessidades de domínio das
necessidades de leitura;

49. AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFRAESTRUTURA
DOMÍNIO RELATÓRIOS
PROCESSOS LEITURATENNANTS

50. INTEGRAÇÃO ENTRE SISTEMAS
Quarta fase

51. Funcionalidades
• Providenciar uma interface de integração
entre sistemas de Service Desk;

54. AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFRAESTRUTURA
PROCESSOS LEITURATENANTS
RELATÓRIOS INTEGRAÇÕESDOMÍNIO

55. PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFRAESTRUTURA
PROCESSOS LEITURATENANTS
RELATÓRIOS INTEGRAÇÕESDOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFRAESTRUTURA
DOMÍNIO RELATÓRIOS
PROCESSOS LEITURATENNANTS
PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFRAESTRUTURA

56. CONSIDERAÇÕES FINAIS
Conclusão

62. Obrigado!