Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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).

Marcel dos Santos

October 30, 2020
Tweet

More Decks by Marcel dos Santos

Other Decks in Programming

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
  33. None
  34. None
  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
  45. None
  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
  55. None
  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
  64. None
  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
  76. None
  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
  82. None
  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
  88. None
  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?