O documento discute a importância de se ter uma visão crítica da arquitetura de software, abordando tópicos como: (1) quem é responsável e afetado pela arquitetura e para que ela serve; (2) a definição de arquitetura de software como conjunto de decisões que influenciam como o software afeta seu contexto; (3) os motivos para se aprender arquitetura, como promover qualidade e ter decisões conscientes.
2. Quem sou eu?
- Desenvolvedor há 12 anos
- Atualmente “Desenvolvedor Gerente”
- Compiladores
- Aplicativos
- Embarcados
- Um pouco de tudo
- Cozinheiro nas horas vagas
3. O que faço atualmente
- CTO - linkedin.com/company/comadre
- Arquiteto
- Líder técnico
- Pau pra toda obra
4. Sobre o que vamos falar hoje
- Por que uma visão crítica?
- O que é arquitetura de software?
- Por que aprender arquitetura de software?
- Para quem é a arquitetura de software?
- Arquitetando sem perder a agilidade
- Como desenvolver pensamento arquitetural?
5. Sobre o que NÃO vamos falar hoje
- Linguagens de programação
- Ferramentas
- UML
- Como montar um sistema que faz X
7. Por que uma visão crítica?
- Quem é responsável pela arquitetura?
- Quem é afetado pela arquitetura?
- Para que serve a arquitetura?
- O que, afinal, significa arquitetar um sistema?
8. Por que uma visão crítica?
- Quem é responsável pela arquitetura?
- Quem é afetado pela arquitetura?
- Para que serve a arquitetura?
- O que, afinal, significa arquitetar um sistema?
12. Por que uma visão crítica?
- Quem é responsável pela arquitetura?
- Quem é afetado pela arquitetura?
- Para que serve a arquitetura?
- O que, afinal, significa arquitetar um sistema?
14. Quem é afetado pela arquitetura?
Arquiteto(a) Devs
Público-alvo
15. Por que uma visão crítica?
- Quem é responsável pela arquitetura?
- Quem é afetado pela arquitetura?
- Para que serve a arquitetura?
- O que, afinal, significa arquitetar um sistema?
17. No modelo tradicional,
a arquitetura é uma
forma de gerir o
trabalho dos devs.
Para que serve a arquitetura?
18. Queremos propor que
a arquitetura seja
pensada de forma
colaborativa.
Para que serve a arquitetura?
19. Para que serve a arquitetura?
- Quem é responsável pela arquitetura?
- Quem é afetado pela arquitetura?
- Para que serve a arquitetura?
- O que, afinal, significa arquitetar um sistema?
34. Por que aprender arquitetura de software?
- Características do software e promoção de qualidade
- Decisões conscientes e inconscientes
- Coordenação, comunicação e vocabulário
- O valor da arquitetura na carreira
35. Por que aprender arquitetura de software?
- Características do software e promoção de qualidades
- Decisões conscientes e inconscientes
- Coordenação, comunicação e vocabulário
- O valor da arquitetura na carreira
41. Por que aprender arquitetura de software?
- Características do software e promoção de qualidades
- Decisões conscientes e inconscientes
- Coordenação, comunicação e vocabulário
- O valor da arquitetura na carreira
45. Tornar a arquitetura
colaborativa e ágil é uma
forma de entender,
visualizar e controlar o
impacto das decisões
Decisões conscientes e inconscientes
46. Por que aprender arquitetura de software?
- Características do software e promoção de qualidades
- Decisões conscientes e inconscientes
- Coordenação, comunicação e vocabulário
- O valor da arquitetura na carreira
47. Por que aprender arquitetura de software?
- Características do software e promoção de qualidades
- Decisões conscientes e inconscientes
- Coordenação, comunicação e vocabulário
- O valor da arquitetura na carreira
49. Para quem é a arquitetura de software?
- Níveis de abstração e visões de sistema
- O modelo C4
- Contextos
- Containers
- Componentes
- Código
- Níveis de abstração, modularidade e coesão
50. Para quem é a arquitetura de software?
- Níveis de abstração e visões de sistema
- O modelo C4
- Contextos
- Containers
- Componentes
- Código
- Níveis de abstração, modularidade e coesão
56. Preocupações no nível de contextos
- Quem são os stakeholders do sistema?
- Com quais outros sistemas o sistema interage?
- Quais os interesses de cada stakeholder?
- Quais são as necessidades de cada sistema?
- O que pode levar o contexto a mudar?
58. Preocupações no nível dos containers
- Quem são os produtos que precisamos construir?
- Quais necessidades cada produto irá cumprir?
- Quem irá interagir com cada sistema?
- Quem irá construir cada sistema?
- Como o processo de produção dos sistemas irá interagir com a estrutura da
empresa?
- O que pode levar os containers a mudarem?
60. Preocupações no nível dos componentes
- Qual a responsabilidade de cada componente? (1 por componente)
- Cada componente define uma unidade coesa?
- Cada componente define uma unidade desacoplada?
- As fronteiras entre os componentes são bem-definidas?
- O que pode levar os componentes a mudarem?
62. Preocupações no nível de código
- Qual a responsabilidade de cada classe/módulo/entidade? (1 por entidade)
- O código segue boas práticas?
- As fronteiras entre os componentes são bem-definidas?
- Aqui já estamos saindo da Arquitetura e entrando na Engenharia de
Software!
65. Arquitetando sem perder a agilidade
- Design é redesign
- Decisões são experimentos
- Fazer é aprender
- Padrões são fundamentos
- Quanto design é design demais?
66. Arquitetando sem perder a agilidade
- Design é redesign
- Decisões são experimentos
- Fazer é aprender
- Padrões são fundamentos
- Quanto design é design demais?
68. Arquitetando sem perder a agilidade
- Design é redesign
- Decisões são experimentos
- Fazer é aprender
- Padrões são fundamentos
- Quanto design é design demais?
69. Você vai errar. Pense
em decisões de
arquitetura como
hipóteses.
Decisões são experimentos
70. Arquitetando sem perder a agilidade
- Design é redesign
- Decisões são experimentos
- Fazer é aprender
- Padrões são fundamentos
- Quanto design é design demais?
71. O seu contexto é único.
Apenas fazendo você vai
saber o que funciona
nele.
Fazer é aprender
72. Arquitetando sem perder a agilidade
- Design é redesign
- Decisões são experimentos
- Fazer é aprender
- Padrões são fundamentos
- Quanto design é design demais?
75. Padrões são bases.
Encaixe eles na sua
arquitetura, não encaixe
sua arquitetura nos
padrões.
Padrões são fundamentos
76. Arquitetando sem perder a agilidade
- Design é redesign
- Decisões são experimentos
- Fazer é aprender
- Padrões são fundamentos
- Quanto design é design demais?
79. Como desenvolver pensamento arquitetural?
- Empatia e investigação
- Divergência e convergência
- Desenvolva sua biblioteca de padrões
- Modelos mentais
80. Como desenvolver pensamento arquitetural?
- Empatia e investigação
- Divergência e convergência
- Desenvolva sua biblioteca de padrões
81. Como desenvolver pensamento arquitetural?
- Empatia e investigação
- Divergência e convergência
- Desenvolva sua biblioteca de padrões
82. Como desenvolver pensamento arquitetural?
- Empatia e investigação
- Divergência e convergência
- Desenvolva sua biblioteca de padrões
84. Em resumo
- Arquitetura existe em um contexto
- Arquitetura é feita para pessoas
- Arquitetura é sobre comunicação e decisões
- Pessoas diferentes precisam ver níveis diferentes do sistema
- Padrões são bases
- Arquitetura ágil é um processo de iteração