Embed Size (px)
DESCRIPTION
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.
Citation preview
Arquitetura evolutiva
por @DenisFerrari
Meta da apresentação
• Através de conceitos, teorias e histórias mostrar o que é importante em cada fase de um 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 externa;• Novas implementações necessitam da
avaliação do todo;• É um processo criativo…
(O TDD é fod* legal pois auxilia as micro-decisões)
O que é arquitetura de software?
A arquitetura de um projeto de software é como
a infraestrutura de uma cidade.
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;
Existe software sem arquitetura?
A figura do arquiteto é essencial?
(O arquiteto deve estar próximo do time de desenvolvimento, assim como o prefeito deveria usar apenas serviços públicos)
Quando a arquitetura de um projeto deve ser definida?
Qual o tamanho ideal de um time de desenvolvimento?
Dois programadores, um designer.
(A qualidade dos integrantes de um time é mais importante do que a quantidade de pessoas)
(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)
(O livro de DDD não é a bíblia e saber arquitetura não faz de você um cara mais legal)
(A interface com o usuário antes da programação)
(A utilização do código antes de sua construção)
(Analisar o comportamento do usuário antes 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 estar alinhada com os conceitos do seu projeto e
não deve definir como você irá trabalhar.
(Cuidado com a política nas decisões).
PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
A arquitetura deve atender ao momento do projeto e
possibilitar a sua evolução.
ESTATÍSTICAS E IMPORTAÇÃOSegunda fase
Funcionalidades
• Ferramenta de importação;• Informações estatísticas sobre a base de
conhecimento;• Interação do usuário com a base de
conhecimento;
(Migração de dados é uma coisa chata)
PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFR
AEST
RUTU
RA
MULTICLIENTESTerceira fase
Funcionalidades
• Multi-Tenant;• Separar necessidades de domínio das
necessidades de leitura;
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFR
AEST
RUTU
RA
DOMÍNIO RELATÓRIOS
PROCESSOS LEITURATENNANTS
INTEGRAÇÃO ENTRE SISTEMASQuarta fase
Funcionalidades
• Providenciar uma interface de integração entre sistemas de Service Desk;
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFR
AEST
RUTU
RA
PROCESSOS LEITURATENANTS
RELATÓRIOS INTEGRAÇÕESDOMÍNIO
PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFR
AEST
RUTU
RAPROCESSOS LEITURATENANTS
RELATÓRIOS INTEGRAÇÕESDOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFR
AEST
RUTU
RA
DOMÍNIO RELATÓRIOS
PROCESSOS LEITURATENNANTS
PERSISTÊNCIA
DOMÍNIO
AUTO-ATENDIMENTO ADMINISTRAÇÃO
APLICAÇÃO
INFR
AEST
RUTU
RA
CONSIDERAÇÕES FINAISConclusão
Obrigado!
