Arquitetura evolutivapor @DenisFerrari
Meta da apresentação• Através de conceitos, teorias e históriasmostrar o que é importante em cada fase deum projeto.
Conceitos
O que é programação?
A programação é como uma redação.
A programação, assim como a redação...• Pede por macro-decisões;• É definida nas micro-decisões;• Depende de valiação exte...
(O TDD é fod* legal pois auxilia as micro-decisões)
O que é arquitetura de software?
A arquiteturade um projeto de software é comoa infraestrutura de uma cidade.
A arquitetura...• Conjunto de macro-decisões;• Conjunto de convenções;• Códigos de base (requisitos não funcionais);• “Def...
Existe software sem arquitetura?
A figura do arquiteto é essencial?
(O arquiteto deve estar próximo do time dedesenvolvimento, assim como o prefeitodeveria usar apenas serviços públicos)
Quando a arquitetura de um projetodeve ser definida?
Qual o tamanho ideal de umtime de desenvolvimento?
Dois programadores, um designer.
(A qualidade dos integrantes de um time é maisimportante do que a quantidade de pessoas)
(Um projeto de software é como uma criança,seu comportamento final dependerá dasinfluências que ele recebeu dos adultos qu...
(O livro de DDD não é a bíblia e saberarquitetura não faz de você um cara mais legal)
(A interface com o usuárioantes da programação)
(A utilização do códigoantes de sua construção)
(Analisar o comportamento do usuárioantes de construir o que você acha importante)
CONCEPÇÃO DO PRODUTOPrimeira fase
Funcionalidades• Base de conhecimento;• Gerenciador de avisos;• Interface de auto-atendimento;• Busca com relevância*;
Tecnologias
Uma tecnologia deve estaralinhada com os conceitos do seu projeto enão deve definir como você irá trabalhar.
(Cuidado com a política nas decisões).
PERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃO
A arquitetura deveatender ao momento do projeto epossibilitar a sua evolução.
ESTATÍSTICAS E IMPORTAÇÃOSegunda fase
Funcionalidades• Ferramenta de importação;• Informações estatísticas sobre a base deconhecimento;• Interação do usuário co...
(Migração de dados é uma coisa chata)
PERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURA
MULTICLIENTESTerceira fase
Funcionalidades• Multi-Tenant;• Separar necessidades de domínio dasnecessidades de leitura;
AUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURADOMÍNIO RELATÓRIOSPROCESSOS LEITURATENNANTS
INTEGRAÇÃO ENTRE SISTEMASQuarta fase
Funcionalidades• Providenciar uma interface de integraçãoentre sistemas de Service Desk;
AUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURAPROCESSOS LEITURATENANTSRELATÓRIOS INTEGRAÇÕESDOMÍNIO
PERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃOAUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURAPROCESSOS LEITURATEN...
CONSIDERAÇÕES FINAISConclusão
Obrigado!
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
DevInCachu 2013: Arquitetura evolutiva
Upcoming SlideShare
Loading in …5
×

DevInCachu 2013: Arquitetura evolutiva

233
-1

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
233
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

DevInCachu 2013: Arquitetura evolutiva

  1. 1. Arquitetura evolutivapor @DenisFerrari
  2. 2. Meta da apresentação• Através de conceitos, teorias e históriasmostrar o que é importante em cada fase deum projeto.
  3. 3. Conceitos
  4. 4. O que é programação?
  5. 5. A programação é como uma redação.
  6. 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 daavaliação do todo;• É um processo criativo…
  7. 7. (O TDD é fod* legal pois auxilia as micro-decisões)
  8. 8. O que é arquitetura de software?
  9. 9. A arquiteturade um projeto de software é comoa infraestrutura de uma cidade.
  10. 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 novasimplementações;• É difícil de mudar;
  11. 11. Existe software sem arquitetura?
  12. 12. A figura do arquiteto é essencial?
  13. 13. (O arquiteto deve estar próximo do time dedesenvolvimento, assim como o prefeitodeveria usar apenas serviços públicos)
  14. 14. Quando a arquitetura de um projetodeve ser definida?
  15. 15. Qual o tamanho ideal de umtime de desenvolvimento?
  16. 16. Dois programadores, um designer.
  17. 17. (A qualidade dos integrantes de um time é maisimportante do que a quantidade de pessoas)
  18. 18. (Um projeto de software é como uma criança,seu comportamento final dependerá dasinfluências que ele recebeu dos adultos queestavam perto durante seu crescimento)
  19. 19. (O livro de DDD não é a bíblia e saberarquitetura não faz de você um cara mais legal)
  20. 20. (A interface com o usuárioantes da programação)
  21. 21. (A utilização do códigoantes de sua construção)
  22. 22. (Analisar o comportamento do usuárioantes de construir o que você acha importante)
  23. 23. CONCEPÇÃO DO PRODUTOPrimeira fase
  24. 24. Funcionalidades• Base de conhecimento;• Gerenciador de avisos;• Interface de auto-atendimento;• Busca com relevância*;
  25. 25. Tecnologias
  26. 26. Uma tecnologia deve estaralinhada com os conceitos do seu projeto enão deve definir como você irá trabalhar.
  27. 27. (Cuidado com a política nas decisões).
  28. 28. PERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃO
  29. 29. A arquitetura deveatender ao momento do projeto epossibilitar a sua evolução.
  30. 30. ESTATÍSTICAS E IMPORTAÇÃOSegunda fase
  31. 31. Funcionalidades• Ferramenta de importação;• Informações estatísticas sobre a base deconhecimento;• Interação do usuário com a base deconhecimento;
  32. 32. (Migração de dados é uma coisa chata)
  33. 33. PERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURA
  34. 34. MULTICLIENTESTerceira fase
  35. 35. Funcionalidades• Multi-Tenant;• Separar necessidades de domínio dasnecessidades de leitura;
  36. 36. AUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURADOMÍNIO RELATÓRIOSPROCESSOS LEITURATENNANTS
  37. 37. INTEGRAÇÃO ENTRE SISTEMASQuarta fase
  38. 38. Funcionalidades• Providenciar uma interface de integraçãoentre sistemas de Service Desk;
  39. 39. AUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURAPROCESSOS LEITURATENANTSRELATÓRIOS INTEGRAÇÕESDOMÍNIO
  40. 40. PERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃOAUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURAPROCESSOS LEITURATENANTSRELATÓRIOS INTEGRAÇÕESDOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURADOMÍNIO RELATÓRIOSPROCESSOS LEITURATENNANTSPERSISTÊNCIADOMÍNIOAUTO-ATENDIMENTO ADMINISTRAÇÃOAPLICAÇÃOINFRAESTRUTURA
  41. 41. CONSIDERAÇÕES FINAISConclusão
  42. 42. Obrigado!

×