Nessa palestra será apresentado um caso real onde a Arquitetura evolutiva possibilitou que um produto inicialmente simples se tornasse uma poderosa ferramenta de integração de softwares para Service Desk. Serão apresentados os marcos do projeto, as tecnologias utilizadas, quais decisões ajudaram a manter o ritmo de evoluções e o que faríamos diferente hoje em dia.

1. Arquitetura evolutiva
por @DenisFerrari

2. Meta da apresentação
• Através de conceitos, teorias e histórias
mostrar o que é importante em cada fase de
um projeto.

3. Conceitos

4. O que é programação?

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

6. 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…

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

8. O que é arquitetura de software?

9. A arquitetura
de um projeto de software é como
a infraestrutura de uma cidade.

10. 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;

11. Existe software sem arquitetura?

12. A figura do arquiteto é essencial?

13. (O arquiteto deve estar próximo do time de
desenvolvimento, assim como o prefeito
deveria usar apenas serviços públicos)

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

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

16. Dois programadores, um designer.

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

18. (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)

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

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

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

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

26. CONCEPÇÃO DO PRODUTO
Primeira fase

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

28. Tecnologias

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

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

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

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

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

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

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

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

43. MULTICLIENTES
Terceira fase

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

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

48. INTEGRAÇÃO ENTRE SISTEMAS
Quarta fase

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

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

53. 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

54. CONSIDERAÇÕES FINAIS
Conclusão

60. Obrigado!