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. 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
  2. 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
  3. "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
  4. "...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
  5. 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
  6. "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
  7. 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
  8. 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
  9. a complexidade essencial é aquela que não pode ser evitada

    e está relacionada a complexidade do domínio
  10. a arquitetura de software in fl uencia na complexidade acidental

    do código de forma positiva ou negativa conforme o contexto
  11. "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
  12. existe uma linha tênue que que delimita a diferença entre

    arquitetura e design de software e isso causa muita confusão
  13. 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
  14. 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
  15. "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
  16. a pessoa arquiteta de software tem como objetivo projetar aplicações

    utilizando conceitos de arquitetura e boas práticas de desenvolvimento
  17. essa pessoa pode atuar como um guia técnico de uma

    equipe que irá conduzir o projeto, arquitetura e implementação
  18. o papel da pessoa arquiteta de software pode ser exercido

    de forma transversal entre as várias pessoas da equipe
  19. ajuda a evitar a fi gura do Ivory Tower Architect

    ou arquiteto na torre de mar fi m
  20. 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
  21. 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
  22. são exemplos de estilos arquiteturais: 
 
 - arquitetura orientada

    a serviços - arquitetura publish-subscribe 
 - arquitetura de plugins 
 - arquitetura de microsserviços 
 - arquitetura REST
  23. um padrão arquitetural é uma solução reutilizável para problemas comuns

    na arquitetura de software dentro de um contexto especí fi co
  24. são exemplos de padrões arquiteturais: 
 
 - model-view-controller -

    onion architecture 
 - arquitetura hexagonal ou ports and adapters 
 - arquitetura limpa 
 - CQRS 
 - event sourcing
  25. uma "big ball of mud" ou grande bola de lama

    é um código com uma arquitetura mal de fi nida…
  26. …e que correções e pequenas evoluções se tornam um grande

    desa fi o pela di fi culdade de compreender o código
  27. "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
  28. "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
  29. "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
  30. ele costuma ser a porta de entrada para a compreensão

    e utilização de padrões de arquitetura no desenvolvimento de software
  31. contudo, ele se mostra insu fi ciente para a organização

    de código em uma parte considerável de aplicações modernas
  32. 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
  33. a arquitetura em camadas é utilizada para organizar a aplicação

    e permite separá-la em camadas com responsabilidades especí fi cas
  34. 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
  35. infraestrutura 
 
 responsável por fornecer os recursos técnicos que

    dão suporte às outras camadas como persistência de dados e I/O
  36. "Is ol ating the d om ain implementati on is

    a pr er equisite f or d om ain-driven design." 
 ― Eric Evans
  37. a arquitetura hexagonal ou arquitetura ports and adapters foi criada

    por Alistair Cockburn e descrita no seu blog em 2005
  38. "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
  39. a ideia é pensar na aplicação como um artefato central

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

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

    comunica e (2) nem quem se comunica com ela
  42. 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
  43. uma porta é uma intenção de comunicação e um adaptador

    é uma implementação da comunicação
  44. a regra de dependência das camadas é sempre de fora

    para dentro, isto é, as camadas internas não tem conhecimento do mundo externo
  45. a utilização da arquitetura ports and adapters torna a aplicação

    isolada de detalhes de implementação e facilmente testável
  46. a arquitetura limpa foi criada por Robert C. Martin e

    possui muitas semelhanças com ports and adapters e onion architecture
  47. a principal semelhança é a separação de responsabilidades que é

    alcançada através da separação de camadas
  48. 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
  49. 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
  50. 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
  51. 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
  52. essa é só a porta de entrada para o fantástico

    mundo da arquitetura de software