Reflexões sobre
Arquitetura de Software
DevinSantos 2015
10 sacadas sobre
Arquitetura de Software
DevinSantos 2015
Tiago Sciência
@_caco
tiagosciencia.com
Projetos
cupong.me comunidadeconteúdo
Arquitetura de Software
SP.
Como pensar sobre
arquitetura de software
no mundo real?
Arquitetura de software de um sistema
consiste na definição dos componentes
de software, suas propriedades
externas, e seus...
Arquitetura de software de um sistema
consiste na definição dos componentes
de software, suas propriedades
externas, e seus...
componentes
propriedades
relacionamentos
comunicação
decisões
reuso
padrões
“Principais elementos
do sistema - as peças
difíceis de mudar. Uma
fundação no qual o resto
precisa ser construído”
- Mart...
Implementação
Design
Arquitetura
Mudanças na arquitetura são caras e são
difíceis de mudar
Modelo Cascata
Como pensar sobre
arquitetura de software
no mundo real?
Pense de forma
pragmática e orientada
ao negócio!
#01
Qual devemos escolher?
Orientado a
interfaces
90% de cobertura de
teste
Domínio rico
Orientado a Serviço
Muito acoplado
Se...
Depende.
Contexto é tudo!
#02
Metáforas para escolher
arquitetura
Tempo de configuração?
Treinamentos?
Ferramentas necessárias?
Justifica o tempo de configuração e o custo?
Mais efetivo?
Mais eficaz?
Mais barato?
Mais flexível?
Mais escalável?
Leve?
Rápido de usar?
Barato?
Mais perigoso?
Mais rápido?
Exige treinamento?
Qual é o tamanho do projeto?
É um projeto temporário?
Quanto mais tempo você
adiar as suas decisões, mais
contextualizadas elas serão!
A complexidade deve
ser justificada!
#03
simplicidade
x
complexidade
Complexidade importa!
Coding to an
interface
Automated
Testing
Domain
Driven Design
Custom DAL
Layered
architecture
SOA
somos pagos por soluções não por código
“Consider all solutions to your task that could
possible work. Implement the simplest solution.
Refactor from there if and...
Simplicidade: a arte de
maximizar a quantidade de
trabalho que não precisou
ser realizado
Princípios por trás do Manifesto...
#04
Teste aquilo que é
mais importante!
#05
Seja eficaz!
Mínimo produto viável
(MPV)
• Escalabilidade
• Custo de manutenção
• Bonito
• Código limpo
• Todas as funcionalidades
• Pe...
"Para uma prática ser considerada boa,
precisa colaborar com a eficácia. Seja
através da maior assertividade nas
entregas (...
#06
Escolha tecnologias
apropriadas ao
negócio!
Camadas da aplicação
Persistência
Domínio
Serviço
Apresentação Web Forms, MVC, WPF, WinForms, Silverlight
Web API, WCF, Se...
Alguns padrões
Transaction
Script
Table
Module
Domain
Model
Active
Record
Níveis de arquitetura
N1 N3
• MVP
• Time pequeno
• Time com menos experiência
• Domínio simples
• Prazos curtos
• Curta du...
#07
Faça DevOps desde o
começo!
#08
Dividir pra
conquistar!
philcalcado.com/2015/09/08/
how_we_ended_up_with_microservices.html
Micro serviços
#09
Combine coisas!
criatividade
=
combinatividade
Exercício:
Faça a engenharia reversa
das coisas
#10
Tenha um bom
repertório e boas
referências!
Referências
Mais Referências
resumindo…
O que é uma boa
arquitetura?
É aquela que atende!
que resolve!
que …
#01 Pense de forma pragmática e orientada ao negócio!
#02 Contexto é tudo!
#03 A complexidade deve ser justificada!
#04 Tes...
Obrigado!
Tiago Sciencia
@_caco
tiagosciencia.com
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
Próximos SlideShares
Carregando em…5
×

Reflexões sobre arquitetura de software

721 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

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

×