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

[Codeminer42 Brownbags] Fundamentos de arquitet...

[Codeminer42 Brownbags] Fundamentos de arquitetura de software

Nesta apresentação, vamos falar um pouco sobre o que é arquitetura de software, desmistificar seus conceitos fundamentais e mostrar que arquitetura não aumenta a complexidade do seu software!

Vídeo: https://www.youtube.com/watch?v=OgqnDBDj49A

Talysson de Oliveira Cassiano

November 03, 2022
Tweet

More Decks by Talysson de Oliveira Cassiano

Other Decks in Programming

Transcript

  1. O que não é? ✗ Organização de pastas e arquivos

    ✗ Conjunto de bibliotecas e frameworks ✗ Onde sua aplicação roda (web, API, CLI, desktop) ✗ Somente um nome ("Clean architecture", "Microservices", "MVC") ✔ Modo como as partes do seu sistema se interagem e têm responsabilidades atribuídas priorizando decisões importantes ✔ Estilos arquiteturais e suas implicações ✔ Princípios e decisões de design ✔ Características que definem o sucesso do sistema ✔ Conhecimento em comum do time sobre o sistema O que é?
  2. Em camadas Pipeline ⋯ Microservices Event-driven Microfrontends ⋯ Estilo de

    arquitetura (Conjunto de trade-offs) Four Layered Architecture Clean architecture Hexagonal Architecture Model-View-Controller Entity-Component-System Flux BLoC ⋯ Padrões arquiteturais Decorator Mediator Repository Data Mapper Application Service Entity Higher-order component Custom hook ⋯ Padrões de projeto (Design patterns) Monolíticas Distribuídas Arquitetura Design
  3. Estilos de arquitetura, Padrões arquiteturais e Padrões de projeto -

    Estilos de arquitetura delimitam um conjunto de limitações e vantagens - Padrões arquiteturais definem como estas vantagens serão aproveitadas e como as limitações serão abordadas - As atribuições de responsabilidades e as decisões importantes começam com estes dois - Em um escopo menor, podemos usar Padrões de projeto para alcançar os objetivos dos Padrões arquiteturais - Padrões arquiteturais estão para arquiteturas assim como Padrões de projeto estão para objetos
  4. “ Responsabilidade: uma obrigação de realizar uma tarefa ou saber

    uma informação "Object Design", Rebecca Wirfs-Brock e Alan McKean
  5. Responsabilidades - As responsabilidades de um objeto definem obrigações de

    ser realizar uma tarefa ou saber uma informação através deste objeto - O conjunto de responsabilidades define o papel de um objeto - Este conjunto deve conter responsabilidades relacionadas de forma a evitar que o objeto tenha mais de um papel - Importante: Lidar com dados de mesma natureza não faz com que duas ou mais responsabilidades sejam relacionadas
  6. 7

  7. 3

  8. Atribuição de responsabilidades - Single Responsibility Principle (SRP): Um objeto

    deve ter uma única responsabilidade - Separation of Concerns (SoC): Uma responsabilidade deve ser desempenhada por um único objeto - SRP + SoC: um objeto deve ter uma única responsabilidade, e este objeto deve bastar para desempenhar esta responsabilidade - Uma boa arquitetura define de maneira efetiva como devemos atribuir responsabilidades às partes do sistema
  9. { 1 1 1 Fluxo da aplicação Regras e validações

    de domínio Banco de dados Exemplo de decisão de design
  10. Níveis de responsabilidade - As responsabilidades são classificados em níveis

    - Dizemos que uma responsabilidade de nível maior que a outra é mais importante que a outra - O nível de uma responsabilidade é medida pela distância daquela responsabilidade em relação às entradas e saídas do sistema em questão
  11. Cadastro de usuário Checa dados do usuário Caso de uso

    (aplicação) Regras de negócio (domínio) Entrada Saída (infraestrutura) 1 1 2 3
  12. Fluxo de dependências vs fluxo de dados - Um bom

    princípio de arquitetura é prezar para que uma responsabilidade mais importante nunca dependa de uma menos importante - É importante que esta regra seja seguida mesmo quando o fluxo de dependências não coincide com o fluxo de dados - Usamos esta técnica para proteger uma responsabilidade mais importante de mudanças feitas numa responsabilidade menos importante - Para alcançar este objetivo, usamos o Dependency Inversion Principle (DIP) e Dependency Injection (DI)
  13. Fluxo de dados Implementa A B Mais importante Menos importante

    Depende de [A] Interface ditada por A Inversão de Dependência (Dependency Inversion) A nem sabe que B existe
  14. CreateUser UserModel Fluxo de dados UserRepository Depende de Implementa CreateUser

    nem sabe que UserModel existe Ambos dependem da interface UserRepository
  15. Características do sistema - A arquitetura impacta em diversas características

    que definem o sucesso de um sistema, mesmo sem levar em conta as funcionalidades do sistema: - Escalabilidade - Tolerância a falhas - Disponibilidade - Segurança - Implantabilidade - Agilidade de desenvolvimento - Manutenibilidade - Apesar destas características não serem a arquitetura, uma boa arquitetura leva em consideração as características que definem o sucesso do sistema
  16. Arquitetura por implicação - Os fatores de sucesso de um

    sistema devem ser bem especificados - A arquitetura deve ser planejada e de conhecimento comum do time, e analisada continuamente - Quando a arquitetura não é planejada nem clara para o time, consideramos um caso do anti-pattern Architecture by implication - O prosseguimento com este anti-pattern pode impactar significativamente no sucesso do sistema - Todo sistema tem uma arquitetura, é preferível que ela seja intencional - A correção deste anti-pattern começa com uma boa definição dos objetivos do sistema e documentação das decisões arquiteturais
  17. Recapitulando - A Topologia de um sistema dita as possibilidades

    de Estilo de arquitetura - Estilos de arquitetura ditam um conjunto de trade-offs deste sistema - Padrões arquiteturais são diretrizes sobre como lidar com esses trade-offs - Adaptamos os Padrões arquiteturais de acordo com a necessidade - Padrões arquiteturais estão para arquiteturas assim como Padrões de projeto estão para objetos - A arquitetura de um sistema é definida por todas estas decisões na intenção de alcançar os fatores de sucesso deste sistema - A arquitetura deve definir bem a atribuição de responsabilidades, ser planejada e clara para o time
  18. - Object Design - Roles, Responsibilities and Colaborations: https://www.informit.com/promotions/object-design-142314 -

    Fundamentals of Software Architecture: An engineering Approach: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/ - Domain-Driven Design - Tackling complexity in the heart of software: https://www.amazon.com.br/Domain-Driven-Design-Eric-Evans/dp/8550800651 - Implementing Domain-Driven Design: https://www.amazon.com.br/Implementando-Domain-Driven-design-Vernon/dp/8576089521/ - Clean Architecture - A Craftsman’s Guide to Software Structure and Design: https://www.amazon.com.br/Arquitetura-Limpa-Artes%C3%A3o-Estrutura-Software/dp/8550804606 - Frontend Architecture Fundamentals: https://blog.codeminer42.com/scalable-frontend-1-architecture-9b80a16b8ec7/ - Dependency Injection in JS/TS: https://blog.codeminer42.com/dependency-injection-in-js-ts-part-1/ - Architecture by implication: https://sourcemaking.com/antipatterns/architecture-by-implication Referências