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.

1. Arquitetura de Software
Uma visão crítica
Pedro Castilho
09/06/2021
/in/pcstl
@coproduto coproduto

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

6. 1: Por que uma visão crítica?

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?

9. Quem é responsável pela arquitetura?
Arquiteto(a) Devs

10. Quem é responsável pela arquitetura?
Arquiteto(a) Devs

11. Quem é responsável pela arquitetura?
Arquiteto(a) Devs
Público-alvo

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?

13. Quem é afetado pela arquitetura?
Arquiteto(a) Devs

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?

16. Para que serve a arquitetura?
Arquiteto(a) Devs

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?

20. 2: O que é arquitetura de software?

21. O que é arquitetura de software?
- Por que fazemos software?
- Para quem fazemos software?
- Onde vive o software?
- O que, afinal, é arquitetura?

22. O que é arquitetura de software?
- Por que fazemos software?
- Para quem fazemos software?
- Onde vive o software?
- O que, afinal, é arquitetura?

23. Fazemos software
para resolver
problemas.
Por que fazemos software?

24. Problemas sempre
surgem de um
contexto.
Por que fazemos software?

25. O que é arquitetura de software?
- Por que fazemos software?
- Para quem fazemos software?
- Onde vive o software?
- O que, afinal, é arquitetura?

26. Um produto de software
é consumido tanto por
seus usuários quanto por
seus produtores.
Para quem fazemos software?

27. O que é arquitetura de software?
- Por que fazemos software?
- Para quem fazemos software?
- Onde vive o software?
- O que, afinal, é arquitetura?

28. O que é arquitetura de software?
- Por que fazemos software?
- Para quem fazemos software?
- Onde vive o software?
- O que, afinal, é arquitetura?

29. O software é produzido e
consumido em um
contexto que estende o
contexto do problema.
Onde vive o software?

30. O problema é dos usuários. A solução estende o contexto.

31. O que é arquitetura de software?
- Por que fazemos software?
- Para quem fazemos software?
- Onde vive o software?
- O que, afinal, é arquitetura?

32. Arquitetura é o conjunto
de decisões técnicas que
influenciam como o
software afeta seu
contexto.
O que, afinal, é arquitetura?

33. 3: Por que aprender arquitetura de software?

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

36. “Quero fazer um
aplicativo onde usuários
mandem mensagens
para outros usuários”

37. Implementação: 1 em
cada 5 mensagens
chega.

38. Além disso, cada
alteração leva 2
meses para ir ao ar.

39. Você não quer um
aplicativo de mensagens,
você quer um aplicativo
de mensagens confiável
e manutenível.

40. Qualidades (“requisitos não-funcionais”)
- Eficiência
- Escalabilidade
- Confiabilidade
- Baixo uso de memória
- Responsividade
- Manutenibilidade
- etc.

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

42. Decisões conscientes e inconscientes
Arquiteto(a) Devs
Decisões

43. O problema é dos usuários. A solução estende o contexto.

44. Decisões conscientes e inconscientes
Arquiteto(a) Devs
Público-alvo

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

48. 4: Para quem é a arquitetura de software?

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

51. Níveis de abstração: O Mapa e o Território

52. Níveis de abstração: O Mapa e o Território

53. Níveis de abstração: O mapa e o território

54. Para quem é a arquitetura de software?
- Níveis de abstração e visões de sistema
- O modelo C4
- Contextos
- Containers
- Componentes
- Código

55. Contextos: Situando o sistema

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?

57. Containers: Descrevendo unidades de trabalho

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?

59. Componentes: Planejando implementações

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?

61. Código: Sujando as mãos

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!

63. Coisas que mudam
juntas devem ser
arquitetadas juntas.

64. 5: Arquitetando sem perder a agilidade

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?

67. Alguém
provavelmente já
resolveu o seu
problema antes.
Design é redesign

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?

73. Padrões são fundamentos

74. Padrões são fundamentos

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?

77. Quanto design é design demais?

78. 6: Como desenvolver pensamento
arquitetural?

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

83. Em resumo

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

85. Em resumo

86. Dúvidas?

87. Muito obrigado!
/in/pcstl
@coproduto @coproduto