Reflexões sobre arquitetura de software
•
7 gostaram•1,030 visualizações
O documento discute 10 princípios para pensar sobre arquitetura de software de forma pragmática e orientada ao negócio. Os princípios incluem: pense no contexto do projeto, justifique a complexidade, teste o que é mais importante, escolha tecnologias apropriadas e combine soluções criativamente. O documento argumenta que uma boa arquitetura atende às necessidades do negócio de forma eficaz.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Reflexões sobre arquitetura de software
Semelhante a Reflexões sobre arquitetura de software (20)
Reflexões sobre arquitetura de software
- 1. Reflexões sobre Arquitetura de Software DevinSantos 2015
- 2. 10 sacadas sobre Arquitetura de Software DevinSantos 2015
- 9. SP.
- 10. Como pensar sobre arquitetura de software no mundo real?
- 11. 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.
- 12. 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.
- 14. “Principais elementos do sistema - as peças difíceis de mudar. Uma fundação no qual o resto precisa ser construído” - Martin Fowler
- 15. Implementação Design Arquitetura Mudanças na arquitetura são caras e são difíceis de mudar
- 16. Modelo Cascata
- 17. Como pensar sobre arquitetura de software no mundo real?
- 18. Pense de forma pragmática e orientada ao negócio! #01
- 19. 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
- 20. Depende.
- 23. Tempo de configuração? Treinamentos? Ferramentas necessárias? Justifica o tempo de configuração e o custo?
- 24. Mais efetivo? Mais eficaz? Mais barato? Mais flexível? Mais escalável?
- 25. Leve? Rápido de usar? Barato? Mais perigoso? Mais rápido? Exige treinamento?
- 26. Qual é o tamanho do projeto? É um projeto temporário?
- 27. Quanto mais tempo você adiar as suas decisões, mais contextualizadas elas serão!
- 28. A complexidade deve ser justificada! #03
- 30. Complexidade importa! Coding to an interface Automated Testing Domain Driven Design Custom DAL Layered architecture SOA
- 33. somos pagos por soluções não por código
- 35. “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
- 36. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser realizado Princípios por trás do Manifesto Ágil
- 37. #04 Teste aquilo que é mais importante!
- 40. #05 Seja eficaz!
- 43. 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
- 45. "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.
- 48. 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
- 52. 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
- 54. #07 Faça DevOps desde o começo!
- 62. Micro serviços
- 70. Exercício: Faça a engenharia reversa das coisas
- 71. #10 Tenha um bom repertório e boas referências!
- 73. Referências
- 74. Mais Referências
- 75. resumindo…
- 76. O que é uma boa arquitetura?
- 77. É aquela que atende! que resolve! que …
- 78. #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!