Reflexões sobre arquitetura de software

595 visualizações

Publicada em

O trabalho de um arquiteto é gerenciar complexidade, não aumentá-la. No entanto, o desenvolvedor se depara com diversos frameworks, siglas e escolhas aparentemente infinitas. Então, como saber quando uma complexidade faz sentido? Nesta palestra vamos refletir sobre quando as abstrações se justificam, e, vamos analisar caminhos a seguir com base em diferentes abordagens para estruturar uma aplicação.

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
595
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
104
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Reflexões sobre arquitetura de software

  1. 1. Reflexões sobre Arquitetura de Software DevinSantos 2015
  2. 2. 10 sacadas sobre Arquitetura de Software DevinSantos 2015
  3. 3. Tiago Sciência @_caco tiagosciencia.com
  4. 4. Projetos cupong.me comunidadeconteúdo
  5. 5. Arquitetura de Software
  6. 6. SP.
  7. 7. Como pensar sobre arquitetura de software no mundo real?
  8. 8. Arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entre projetos.
  9. 9. Arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entre projetos.
  10. 10. componentes propriedades relacionamentos comunicação decisões reuso padrões
  11. 11. “Principais elementos do sistema - as peças difíceis de mudar. Uma fundação no qual o resto precisa ser construído” - Martin Fowler
  12. 12. Implementação Design Arquitetura Mudanças na arquitetura são caras e são difíceis de mudar
  13. 13. Modelo Cascata
  14. 14. Como pensar sobre arquitetura de software no mundo real?
  15. 15. Pense de forma pragmática e orientada ao negócio! #01
  16. 16. Qual devemos escolher? Orientado a interfaces 90% de cobertura de teste Domínio rico Orientado a Serviço Muito acoplado Sem testes Sem divisão em camadas Sem API
  17. 17. Depende.
  18. 18. Contexto é tudo! #02
  19. 19. Metáforas para escolher arquitetura
  20. 20. Tempo de configuração? Treinamentos? Ferramentas necessárias? Justifica o tempo de configuração e o custo?
  21. 21. Mais efetivo? Mais eficaz? Mais barato? Mais flexível? Mais escalável?
  22. 22. Leve? Rápido de usar? Barato? Mais perigoso? Mais rápido? Exige treinamento?
  23. 23. Qual é o tamanho do projeto? É um projeto temporário?
  24. 24. Quanto mais tempo você adiar as suas decisões, mais contextualizadas elas serão!
  25. 25. A complexidade deve ser justificada! #03
  26. 26. simplicidade x complexidade
  27. 27. Complexidade importa! Coding to an interface Automated Testing Domain Driven Design Custom DAL Layered architecture SOA
  28. 28. somos pagos por soluções não por código
  29. 29. “Consider all solutions to your task that could possible work. Implement the simplest solution. Refactor from there if and when needed… you will always wind up with a system that is just right for what it does so far… That it just where you want to be. Everything just right, nothing added that isn’t needed.” - Ron Jeffries
  30. 30. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser realizado Princípios por trás do Manifesto Ágil
  31. 31. #04 Teste aquilo que é mais importante!
  32. 32. #05 Seja eficaz!
  33. 33. Mínimo produto viável (MPV) • Escalabilidade • Custo de manutenção • Bonito • Código limpo • Todas as funcionalidades • Performance • Segurança • (Mas precisa funcionar) O que você não precisa se preocupar
  34. 34. "Para uma prática ser considerada boa, precisa colaborar com a eficácia. Seja através da maior assertividade nas entregas (entregar aquilo que resolve o problema do cliente). Seja através da redução do custo total da propriedade ou reduzindo o custo de desenvolvimento." - Elemar Jr.
  35. 35. #06 Escolha tecnologias apropriadas ao negócio!
  36. 36. Camadas da aplicação Persistência Domínio Serviço Apresentação Web Forms, MVC, WPF, WinForms, Silverlight Web API, WCF, ServiceStack C#, VB.NET, F#, Javascript EF, NHibernate, Dapper, ADO.NET
  37. 37. Alguns padrões Transaction Script Table Module Domain Model Active Record
  38. 38. Níveis de arquitetura N1 N3 • MVP • Time pequeno • Time com menos experiência • Domínio simples • Prazos curtos • Curta duração • Sem preocupação com segurança • Produto • Time grande • Time com mais experiência • Domínio complexo • Prazos flexíveis • Longa duração • Segurança é importante
  39. 39. #07 Faça DevOps desde o começo!
  40. 40. #08 Dividir pra conquistar!
  41. 41. philcalcado.com/2015/09/08/ how_we_ended_up_with_microservices.html
  42. 42. Micro serviços
  43. 43. #09 Combine coisas!
  44. 44. criatividade = combinatividade
  45. 45. Exercício: Faça a engenharia reversa das coisas
  46. 46. #10 Tenha um bom repertório e boas referências!
  47. 47. Referências
  48. 48. Mais Referências
  49. 49. resumindo…
  50. 50. O que é uma boa arquitetura?
  51. 51. É aquela que atende! que resolve! que …
  52. 52. #01 Pense de forma pragmática e orientada ao negócio! #02 Contexto é tudo! #03 A complexidade deve ser justificada! #04 Teste aquilo que é mais importante! #05 Seja eficaz! #06 Escolha tecnologias apropriadas ao negócio! #07 Faça DevOps desde o começo! #08 Dividir pra conquistar! #09 Combine coisas. Use a *criatividade*! #10 Tenha um bom repertório e boas referências!
  53. 53. Obrigado! Tiago Sciencia @_caco tiagosciencia.com

×