O bê-a-bá da arquitetura de software!

Nesta palestra vamos falar sobre arquitetura de software e o impacto que ela tem no projeto de uma aplicação. Vamos introduzir conceitos como arquitetura e design de código, entender qual é a sua importância e falar sobre complexidade essencial e acidental. E, por fim, apresentaremos os estilos e padrões arquiteturais mais utilizados como MVC, arquitetura em camadas e arquitetura hexagonal (ou ports and adapters) e arquitetura limpa (clean architecture).

Transcript

1. Marcel Gonçalves dos Santos @marcelgsantos arquitetura de software O bê-a-bá da
2. pensandonaweb.com.br desenvolvedor web full-stack Marcel Gonçalves dos Santos @marcelgsantos
3. @phpsp phpsp.org.br
4. Interaja nas mídias sociais! 
 
 - fale sobre o evento, palestrantes e conteúdo - tire fotos do evento e publique 
 - interaja com outros participantes do evento - tire dúvidas ou dê feedbacks para os palestrantes
5. O que é 
 arquitetura de software?
6. a arquitetura de software de um sistema consiste na de fi nição dos componentes de software, suas propriedades externas e seus relacionamentos com outros softwares
7. "A g oo d ar chitect ur e is imp or tant, oth er wise it bec om es sl ow er and m or e ex pensive to add new capabilities in the fut ur e." 
 ― M ar tin F ow l e
8. "...g oo d ar chitect ur e is s om ething that supp or ts its ow n ev ol uti o , and is deeply int er twined with pro gr amming." 
 ― M ar tin F ow l e
9. uma boa arquitetura: 
 
 1. torna evidente a organização do código 2. permite a evolução do código com pouca fricção 3. entrega valor de negócio de forma consistente 4. garante a qualidade e con fi abilidade do software
10. a arquitetura de software permite lidar com a complexidade de software de forma mais controlada
11. Complexidade acidental e complexidade essencial
12. o domínio é o coração do software e onde estão as regras de negócio
13. "The he ar t of softw ar e is its ability to s ol ve d om ain-related problems f or its us er ." 
 ― Eric Evans, D om ain-Driven Design
14. o domínio possui uma complexidade intrínseca, isto é, a complexidade do problema a ser resolvido
15. a complexidade acidental é aquela que é decorrente da solução adotada
16. exemplo 01 
 escolher entre utilizar monolitos ou microsserviços, framework A ou B, banco de dados relacionais ou não-relacionais são exemplos de complexidades acidentais
17. a complexidade essencial é aquela que é inerente ao problema a ser resolvido
18. exemplo 02 
 a coordenação de motoristas de aplicativos, isto é, identi fi car os motoristas disponíveis nas imediações da solicitação de uma chamada é um exemplo de complexidade essencial pois faz parte do problema
19. a complexidade essencial é aquela que não pode ser evitada e está relacionada a complexidade do domínio
20. a arquitetura de software in fl uencia na complexidade acidental do código de forma positiva ou negativa conforme o contexto
21. "It's the duty of the ar chitect to s ol ve the problems inh er ent in essential c om pl ex ity with ou t in tr oducing accidental c om pl ex ity." 
 ― Neil F or d
22. Diferença entre arquitetura 
 e design de software
23. existe uma linha tênue que que delimita a diferença entre arquitetura e design de software e isso causa muita confusão
24. a arquitetura de software pode ser vista como uma organização de alto nível dos componentes de um software, isto é, sobre aspectos mais genéricos e de negócio
25. o design de software pode ser visto como uma organização de baixo nível dos componentes de um software, isto é, no nível do código como módulos, classes e funções
26. "Atividades relaci on adas a ar quitet ur a de softw ar e são sempre de design. En tr etanto, nem todas atividades de design são sobre ar quitet ur a." 
 ― Elem ar Juni o
27. O que faz um(a) 
 arquiteto(a) de software?
28. a pessoa arquiteta de software tem como objetivo projetar aplicações utilizando conceitos de arquitetura e boas práticas de desenvolvimento
29. deve-se levar em consideração a estratégia da empresa na tomada de decisão técnica
30. essa pessoa pode atuar como um guia técnico de uma equipe que irá conduzir o projeto, arquitetura e implementação
31. o papel da pessoa arquiteta de software pode ser exercido de forma transversal entre as várias pessoas da equipe
32. ajuda a evitar a fi gura do Ivory Tower Architect ou arquiteto na torre de mar fi m
35. O que são estilos 
 e padrões arquiteturais?
36. um estilo arquitetural de fi ne como o código é organizado sob uma perspectiva de alto nível, isto é, como os módulos de alto nível de uma aplicação estão relacionados
37. são exemplos de estilos arquiteturais: 
 
 - arquitetura monolítica - arquitetura baseada em componentes 
 - arquitetura cliente-servidor 
 - arquitetura em camadas 
 - pipes and fi lters 
 - arquitetura orientada a eventos
38. são exemplos de estilos arquiteturais: 
 
 - arquitetura orientada a serviços - arquitetura publish-subscribe 
 - arquitetura de plugins 
 - arquitetura de microsserviços 
 - arquitetura REST
39. um padrão arquitetural é uma solução reutilizável para problemas comuns na arquitetura de software dentro de um contexto especí fi co
40. um padrão arquitetural é uma forma de implementar um estilo arquitetural
41. são exemplos de padrões arquiteturais: 
 
 - model-view-controller - onion architecture 
 - arquitetura hexagonal ou ports and adapters 
 - arquitetura limpa 
 - CQRS 
 - event sourcing
42. Arquitetura spaghetti 
 ou big ball of mud
43. uma "big ball of mud" ou grande bola de lama é um código com uma arquitetura mal de fi nida…
44. …e que correções e pequenas evoluções se tornam um grande desa fi o pela di fi culdade de compreender o código
46. "A big ball of mud is haphaz ar dly s tr uct ur ed, sprawling, sl op py, duct-tape and bailing w ir e, spaghe tt i code jungle.” 
 ― Brian F oo te and Joseph Yod er , 1999
47. "Uma gr ande b ol a de lama é uma selva de código espaguete, aleat or iamente es tr ut ur ado, espalhado, desle ix ado e cheio de fita adesiva." 
 ― Brian F oo te and Joseph Yod er , 1999
48. "Questi on s ab ou t wheth er design is necess ar y or aff or dable ar e quite beside the p oi nt: design is inevitable. The alt er native to g oo d design is bad design, not no design at all." 
 ― D ou glas M ar tin
49. Arquitetura 
 model-view-controller
50. o MVC ou Model-View-Controller fi cou conhecida com a popularização de frameworks web
51. ele permite a separação da aplicação nas três camadas seguintes: controller, model e view
52. controller 
 recebe a requisição HTTP e orquestra o acesso a model e a renderização da view
53. model 
 camada responsável pelas regras de negócio e acesso a dados
54. view 
 camada responsável pela representação visual que será enviada ao cliente
56. é um padrão de fácil compreensão e amplamente conhecido entre desenvolvedores(as)
57. ele costuma ser a porta de entrada para a compreensão e utilização de padrões de arquitetura no desenvolvimento de software
58. contudo, ele se mostra insu fi ciente para a organização de código em uma parte considerável de aplicações modernas
59. ele pode levar para o surgimento do anti- pattern fat controllers no código com controllers com regras de negócio e cada vez maiores
60. o código fi ca altamente acoplado ao mecanismo de entrega
61. Arquitetura em camadas
62. a arquitetura em camadas é utilizada para organizar a aplicação e permite separá-la em camadas com responsabilidades especí fi cas
63. cada camada depende somente das camadas abaixo (direta ou indiretamente) e não tem conhecimento das camadas acima
65. interface de usuário 
 
 responsável por exibir informações e interpretar comandos do usuário
66. aplicação 
 
 responsável por conectar a camada de interface de usuário com as outras camadas
67. domínio 
 
 responsável por conter os conceitos e regras de negócio relacionados ao domínio e é o principal foco do domain-driven design
68. infraestrutura 
 
 responsável por fornecer os recursos técnicos que dão suporte às outras camadas como persistência de dados e I/O
69. "Is ol ating the d om ain implementati on is a pr er equisite f or d om ain-driven design." 
 ― Eric Evans
70. Arquitetura hexagonal 
 ou ports and adapters
71. a arquitetura hexagonal ou arquitetura ports and adapters foi criada por Alistair Cockburn e descrita no seu blog em 2005
72. "All ow an applicati o to equally be driven by us er s, pro gr ams, aut om ated test or batch s cr ipts, and to be devel op ed and tested in is ol ati o from its eventual run-time devices and databases." 
 ― Alista ir Cockb ur n
73. a ideia é pensar na aplicação como um artefato central de um sistema em que toda entrada e saída…
74. …aconteça através de uma porta que isola a aplicação de ferramentas externas e mecanismos de entrega
75. a aplicação não deve saber (1) com quem ela se comunica e (2) nem quem se comunica com ela
77. uma porta é um ponto de entrada ou saída da aplicação e pode ser representada por uma interface na sua linguagem de programação
78. um adaptador é a implementação da comunicação do mundo externo e a aplicação e vice-versa
79. uma porta é uma intenção de comunicação e um adaptador é uma implementação da comunicação
80. costuma-se implementar a arquitetura hexagonal com três camadas: infraestrutura, aplicação e domínio
81. a regra de dependência das camadas é sempre de fora para dentro, isto é, as camadas internas não tem conhecimento do mundo externo
83. pode-se alcançar esse comportamento através do princípio da inversão de dependência
84. a utilização da arquitetura ports and adapters torna a aplicação isolada de detalhes de implementação e facilmente testável
85. Arquitetura limpa 
 ou clean architecture
86. a arquitetura limpa foi criada por Robert C. Martin e possui muitas semelhanças com ports and adapters e onion architecture
87. a principal semelhança é a separação de responsabilidades que é alcançada através da separação de camadas
89. a regra de dependência é outro elemento conceitual importante na arquitetura limpa
90. ao criar um software separado em camadas e que obedece a regra de dependência ele se torna facilmente testável e independente de elementos externos
91. Conclusão
92. a arquitetura de software é uma disciplina importante no desenvolvimento de software que permite criar um código aderente ao negócio e que evolua de forma consistente
93. existem inúmeros conceitos relacionados a design e arquitetura de software que são fundamentais para a construção de um software com uma boa arquitetura
94. desde princípios básicos como coesão e acoplamento, passando por conceitos como separação de responsabilidade e tocando em outros princípios como o SOLID
95. essa é só a porta de entrada para o fantástico mundo da arquitetura de software
96. vá em frente e divirta-se!
97. Referências
98. bit.ly/palestra-arquitetura-de-software
99. Avalie!
100. @marcelgsantos speakerdeck.com/marcelgsantos Obrigado. Perguntas?