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

52711e2157a6fed933b0361cc06a6953?s=128

Marcel dos Santos

October 30, 2020
Tweet

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 definição

    dos componentes de software, suas propriedades externas e seus relacionamentos com outros softwares
  7. "A good architecture is important, otherwise it becomes slower and

    more expensive to add new capabilities in the future." 
 ― Martin Fowler
  8. "...good architecture is something that supports its own evolution, and

    is deeply intertwined with programming." 
 ― Martin Fowler
  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 confiabilidade 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 heart of software is its ability to solve domain-related

    problems for its user." 
 ― Eric Evans, Domain-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

    é, identificar 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 influencia na complexidade acidental do código

    de forma positiva ou negativa conforme o contexto
  21. "It's the duty of the architect to solve the problems

    inherent in essential complexity without introducing accidental complexity."
 ― Neil Ford
  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 relacionadas a arquitetura de software são sempre de design.

    Entretanto, nem todas atividades de design são sobre arquitetura." 
 ― Elemar Junior
  27. O que faz um(a) 
 arquiteto(a) de software?

  28. o(a) arquiteto(a) 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 de arquiteto(a) de software pode ser exercido de

    forma transversal entre as várias pessoas da equipe
  32. ajuda a evitar a figura do Ivory Tower Architect ou

    arquiteto na torre de marfim
  33. None
  34. None
  35. O que são estilos 
 e padrões arquiteturais?

  36. um estilo arquitetural define 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 filters
 - arquitetura orientada a eventos
  38. são exemplos de estilos arquiteturais:
 
 - arquitetura orientada a

    serviços - arquitetura publish-subscribe
 - arquitetura de plug-ins
 - 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ífico
  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 definida…
  44. …e que correções e pequenas evoluções se tornam um grande

    desafio pela dificuldade de compreender o código
  45. None
  46. "A big ball of mud is haphazardly structured, sprawling, sloppy,

    duct-tape and bailing wire, spaghetti code jungle.” 
 ― Brian Foote and Joseph Yoder, 1999
  47. "Uma grande bola de lama é uma selva de código

    espaguete, aleatoriamente estruturado, espalhado, desleixado e cheio de fita adesiva." 
 ― Brian Foote and Joseph Yoder, 1999
  48. Arquitetura 
 model-view-controller

  49. o MVC ou Model-View-Controller ficou conhecida com a popularização de

    frameworks web
  50. ele permite a separação da aplicação nas três camadas seguintes:

    controller, model e view
  51. controller
 recebe a requisição HTTP e orquestra o acesso a

    model e a renderização da view
  52. model
 camada responsável pelas regras de negócio e acesso a

    dados
  53. view
 camada responsável pela representação visual que será enviada ao

    cliente
  54. None
  55. é um padrão de fácil compreensão e amplamente conhecido entre

    desenvolvedores(as)
  56. ele costuma ser a porta de entrada para a compreensão

    e utilização de padrões de arquitetura no desenvolvimento de software
  57. contudo, ele se mostra insuficiente para a organização de código

    em uma parte considerável de aplicações modernas
  58. 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
  59. o código fica altamente acoplado ao mecanismo de entrega

  60. Arquitetura em camadas

  61. a arquitetura em camadas é utilizada para organizar a aplicação

    e permite separá-la em camadas com responsabilidades específicas
  62. cada camada depende somente das camadas abaixo (direta ou indiretamente)

    e não tem conhecimento das camadas acima
  63. None
  64. interface de usuário
 
 responsável por exibir informações e interpretar

    comandos do usuário
  65. aplicação
 
 responsável por conectar a camada de interface de

    usuário com as outras camadas
  66. 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
  67. infraestrutura
 
 responsável por fornecer os recursos técnicos que dão

    suporte às outras camadas como persistência de dados e I/O
  68. "Isolating the domain implementation is a prerequisite for domain-driven design."


    ― Eric Evans
  69. Arquitetura hexagonal 
 ou ports and adapters

  70. a arquitetura hexagonal ou arquitetura ports and adapters foi criada

    por Alistair Cockburn e descrita no seu blog em 2005
  71. "Allow an application to equally be driven by users, programs,

    automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases."
 ― Alistair Cockburn
  72. a ideia é pensar na aplicação como um artefato central

    de um sistema em que toda entrada e saída…
  73. …aconteça através de uma porta que isola a aplicação de

    ferramentas externas e mecanismos de entrega
  74. a aplicação não deve saber (1) com quem ela se

    comunica e (2) nem quem se comunica com ela
  75. None
  76. 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
  77. um adaptador é a implementação da comunicação do mundo externo

    e a aplicação e vice-versa
  78. uma porta é uma intenção de comunicação e um adaptador

    é uma implementação da comunicação
  79. costuma-se implementar a arquitetura hexagonal com três camadas: infraestrutura, aplicação

    e domínio
  80. a regra de dependência das camadas é sempre de fora

    para dentro, isto é, as camadas internas não tem conhecimento do mundo externo
  81. None
  82. pode-se alcançar esse comportamento através do princípio da inversão de

    dependência
  83. a utilização da arquitetura ports and adapters torna a aplicação

    isolada de detalhes de implementação e facilmente testável
  84. Conclusão

  85. 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
  86. 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
  87. 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
  88. essa é só a porta de entrada para o fantástico

    mundo da arquitetura de software
  89. vá em frente e divirta-se!

  90. Referências

  91. bit.ly/palestra-arquitetura-de-software

  92. Avalie!

  93. @marcelgsantos speakerdeck.com/marcelgsantos Obrigado. Perguntas?