Transferir como PDF, PPTX
Carregado porTiago Sciencia
Reflexões sobre arquitetura de software
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.
![[DevDay2018] Arquitetura de Software num cenário de incertezas - Arquitetura ...](https://cdn.slidesharecdn.com/ss_thumbnails/devday2018-paulovich1-180901143034-thumbnail.jpg?width=640&height=640&fit=bounds)
Reflexões sobre arquitetura de software
- 1. Reflexões sobre Arquitetura deSoftware DevinSantos 2015
- 2. 10 sacadas sobre Arquiteturade Software DevinSantos 2015
- 3.
- 4.
- 8.
- 9.
- 10. Como pensar sobre arquiteturade software no mundo real?
- 11. Arquitetura de softwarede 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 softwarede 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.
- 13.
- 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 arquiteturasão caras e são difíceis de mudar
- 16.
- 17. Como pensar sobre arquiteturade software no mundo real?
- 18. Pense de forma pragmáticae orientada ao negócio! #01
- 19. Qual devemos escolher? Orientadoa 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.
- 21.
- 22.
- 23. Tempo de configuração? Treinamentos? Ferramentasnecessárias? Justifica o tempo de configuração e o custo?
- 24. Mais efetivo? Mais eficaz? Maisbarato? Mais flexível? Mais escalável?
- 25. Leve? Rápido de usar? Barato? Maisperigoso? Mais rápido? Exige treinamento?
- 26. Qual é otamanho do projeto? É um projeto temporário?
- 27. Quanto mais tempovocê adiar as suas decisões, mais contextualizadas elas serão!
- 28. A complexidade deve serjustificada! #03
- 29.
- 30. Complexidade importa! Coding toan interface Automated Testing Domain Driven Design Custom DAL Layered architecture SOA
- 33. somos pagos porsoluções não por código
- 35. “Consider all solutionsto 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 artede 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.
- 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áticaser 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.
- 46.
- 48. Camadas da aplicação Persistência Domínio Serviço ApresentaçãoWeb Forms, MVC, WPF, WinForms, Silverlight Web API, WCF, ServiceStack C#, VB.NET, F#, Javascript EF, NHibernate, Dapper, ADO.NET
- 49.
- 52. Níveis de arquitetura N1N3 • 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 desdeo começo!
- 58.
- 59.
- 62.
- 63.
- 67.
- 70. Exercício: Faça a engenhariareversa das coisas
- 71. #10 Tenha um bom repertórioe boas referências!
- 73.
- 74.
- 75.
- 76. O que éuma boa arquitetura?
- 77. É aquela queatende! que resolve! que …
- 78. #01 Pense deforma 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!
- 79.