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
   

   View Slide

2. pensandonaweb.com.br
   desenvolvedor web full-stack
   Marcel Gonçalves dos Santos
   @marcelgsantos
   

   View Slide

3. @phpsp
   phpsp.org.br
   

   View Slide

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
   

   View Slide

5. O que é
   

   arquitetura de software?
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

10. a arquitetura de software permite lidar com
    a complexidade de software de forma mais
    controlada
    

    View Slide

11. Complexidade acidental
    
    
    e complexidade essencial
    

    View Slide

12. o domínio é o coração do software e onde
    estão as regras de negócio
    

    View Slide

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
    

    View Slide

14. o domínio possui uma complexidade
    intrínseca, isto é, a complexidade do
    problema a ser resolvido
    

    View Slide

15. a complexidade acidental é aquela que é
    decorrente da solução adotada
    

    View Slide

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
    

    View Slide

17. a complexidade essencial é aquela que é
    inerente ao problema a ser resolvido
    

    View Slide

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
    

    View Slide

19. a complexidade essencial é aquela que
    
    
    não pode ser evitada e está relacionada
    
    
    a complexidade do domínio
    

    View Slide

20. a arquitetura de software in
    fl
    uencia na
    complexidade acidental do código de forma
    positiva ou negativa conforme o contexto
    

    View Slide

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
    

    View Slide

22. Diferença entre arquitetura
    

    e design de software
    

    View Slide

23. existe uma linha tênue que que delimita a
    diferença entre arquitetura e design de
    software e isso causa muita confusão
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. O que faz um(a)
    

    arquiteto(a) de software?
    

    View Slide

28. a pessoa arquiteta de software tem como
    objetivo projetar aplicações utilizando
    conceitos de arquitetura e boas práticas de
    desenvolvimento
    

    View Slide

29. deve-se levar em consideração a estratégia
    da empresa na tomada de decisão técnica
    

    View Slide

30. essa pessoa pode atuar como um guia
    técnico de uma equipe que irá conduzir o
    projeto, arquitetura e implementação
    

    View Slide

31. o papel da pessoa arquiteta de software
    pode ser exercido de forma transversal
    entre as várias pessoas da equipe
    

    View Slide

32. ajuda a evitar a
    fi
    gura do Ivory Tower
    Architect ou arquiteto na torre de mar
    fi
    m
    

    View Slide

33. View Slide

34. View Slide

35. O que são estilos
    

    e padrões arquiteturais?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

38. são exemplos de estilos arquiteturais:
    

    

    - arquitetura orientada a serviços
    
    
    - arquitetura publish-subscribe
    

    - arquitetura de plugins
    

    - arquitetura de microsserviços
    

    - arquitetura REST
    

    View Slide

39. um padrão arquitetural é uma solução
    reutilizável para problemas comuns na
    arquitetura de software dentro de um
    contexto especí
    fi
    co
    

    View Slide

40. um padrão arquitetural é uma forma de
    implementar um estilo arquitetural
    

    View Slide

41. são exemplos de padrões arquiteturais:
    

    

    - model-view-controller
    
    
    - onion architecture
    

    - arquitetura hexagonal ou ports and adapters
    

    - arquitetura limpa
    

    - CQRS
    

    - event sourcing
    

    View Slide

42. Arquitetura spaghetti
    

    ou big ball of mud
    

    View Slide

43. uma "big ball of mud" ou grande bola de
    lama é um código com uma arquitetura mal
    de
    fi
    nida…
    

    View Slide

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
    

    View Slide

45. View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

49. Arquitetura
    

    model-view-controller
    

    View Slide

50. o MVC ou Model-View-Controller
    fi
    cou
    conhecida com a popularização de
    frameworks web
    

    View Slide

51. ele permite a separação da aplicação nas
    três camadas seguintes: controller, model e
    view
    

    View Slide

52. controller
    

    recebe a requisição HTTP e orquestra o
    acesso a model e a renderização da view
    

    View Slide

53. model
    

    camada responsável pelas regras de negócio
    e acesso a dados
    

    View Slide

54. view
    

    camada responsável pela representação
    visual que será enviada ao cliente
    

    View Slide

55. View Slide

56. é um padrão de fácil compreensão e
    amplamente conhecido entre
    desenvolvedores(as)
    

    View Slide

57. ele costuma ser a porta de entrada para a
    compreensão e utilização de padrões de
    arquitetura no desenvolvimento de software
    

    View Slide

58. contudo, ele se mostra insu
    fi
    ciente para a
    organização de código em uma parte
    considerável de aplicações modernas
    

    View Slide

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
    

    View Slide

60. o código
    fi
    ca altamente acoplado ao
    mecanismo de entrega
    

    View Slide

61. Arquitetura
    
    
    em camadas
    

    View Slide

62. a arquitetura em camadas é utilizada para
    organizar a aplicação e permite separá-la em
    camadas com responsabilidades especí
    fi
    cas
    

    View Slide

63. cada camada depende somente das
    camadas abaixo (direta ou indiretamente) e
    não tem conhecimento das camadas acima
    

    View Slide

64. View Slide

65. interface de usuário
    

    

    responsável por exibir informações e
    interpretar comandos do usuário
    

    View Slide

66. aplicação
    

    

    responsável por conectar a camada de
    interface de usuário com as outras camadas
    

    View Slide

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
    

    View Slide

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
    

    View Slide

69. "Is
    ol
    ating the d
    om
    ain implementati
    on
    is a
    pr
    er
    equisite f
    or
    d
    om
    ain-driven design."
    

    ― Eric Evans
    

    View Slide

70. Arquitetura hexagonal
    

    ou ports and adapters
    

    View Slide

71. a arquitetura hexagonal ou arquitetura
    ports and adapters foi criada por Alistair
    Cockburn e descrita no seu blog em 2005
    

    View Slide

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
    

    View Slide

73. a ideia é pensar na aplicação como um
    artefato central de um sistema em que toda
    entrada e saída…
    

    View Slide

74. …aconteça através de uma porta que isola a
    aplicação de ferramentas externas e
    mecanismos de entrega
    

    View Slide

75. a aplicação não deve saber (1) com quem
    
    
    ela se comunica e (2) nem quem se
    
    
    comunica com ela
    

    View Slide

76. View Slide

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
    

    View Slide

78. um adaptador é a implementação da
    comunicação do mundo externo e a
    aplicação e vice-versa
    

    View Slide

79. uma porta é uma intenção de comunicação
    e um adaptador é uma implementação da
    comunicação
    

    View Slide

80. costuma-se implementar a arquitetura
    hexagonal com três camadas:
    infraestrutura, aplicação e domínio
    

    View Slide

81. a regra de dependência das camadas é
    sempre de fora para dentro, isto é, as
    camadas internas não tem conhecimento do
    mundo externo
    

    View Slide

82. View Slide

83. pode-se alcançar esse comportamento
    através do princípio da inversão de
    dependência
    

    View Slide

84. a utilização da arquitetura ports and
    adapters torna a aplicação isolada de
    detalhes de implementação e facilmente
    testável
    

    View Slide

85. Arquitetura limpa
    

    ou clean architecture
    

    View Slide

86. a arquitetura limpa foi criada por Robert C.
    Martin e possui muitas semelhanças com
    ports and adapters e onion architecture
    

    View Slide

87. a principal semelhança é a separação de
    responsabilidades que é alcançada através
    da separação de camadas
    

    View Slide

88. View Slide

89. a regra de dependência é outro elemento
    conceitual importante na arquitetura limpa
    

    View Slide

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
    

    View Slide

91. Conclusão
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

95. essa é só a porta de entrada para o
    fantástico mundo da arquitetura de software
    

    View Slide

96. vá em frente e divirta-se!
    

    View Slide

97. Referências
    

    View Slide

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

    View Slide

99. Avalie!
    

    View Slide

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

     View Slide