[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

1. Fundamentos de arquitetura de software
2. Talysson @talyssonoc beacons.ai/talyssonoc Codeminer42
3. O que é, e o que não é? Arquitetura de software
4. 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 é?
5. Estilos de arquitetura, Padrões arquiteturais e Padrões de projeto Qual a diferença?
6. Em camadas Pipeline ⋯ Microservices Event-driven Microfrontends ⋯ Monolítica Distribuída Topologia Estilo de arquitetura (Conjunto de trade-offs)
7. 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
8. 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
9. O que são? Onde vivem? Responsabilidades
10. “ Responsabilidade: uma obrigação de realizar uma tarefa ou saber uma informação "Object Design", Rebecca Wirfs-Brock e Alan McKean
11. 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
14. Separation of Concerns (SoC) & Single Responsibility Principle (SRP) Atribuição de responsabilidades
15. 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
18. X Fere o Single Responsibility Principle
20. X Fere Separation of Concerns
21. Fere Separation of Concerns X Fere o Single Responsibility Principle X
22. ✓ ✓
23. { 1 1 1 Fluxo da aplicação Regras e validações de domínio Banco de dados Exemplo de decisão de design
24. Algumas responsabilidades são mais importantes que as outras Níveis de responsabilidades
25. 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
26. 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
27. Níveis de responsabilidade Domínio Casos de uso (aplicação) Entrada & Saída (infraestrutura) > >
28. Dependency Inversion Principle (DIP) & Dependency Injection (DI) Fluxo de dependências vs fluxo de dados
29. 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)
30. A B Fluxo de dados Mais importante Menos importante Depende de
31. A B Mais importante Menos importante Fluxo de dependência Fluxo de dados
32. 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
33. CreateUser UserModel Fluxo de dados Depende de
34. CreateUser UserModel Fluxo de dados UserRepository Depende de Implementa CreateUser nem sabe que UserModel existe Ambos dependem da interface UserRepository
35. Injeção de dependência (Dependency Injection) { Exemplo de decisão de design
36. Características de sucesso do sistema Impactadas por decisões da arquitetura
37. 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
38. Seu time conhece e planeja a arquitetura do projeto? Problema: Arquitetura por implicação
39. 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
40. 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
41. - 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
42. Obrigado! @talyssonoc beacons.ai/talyssonoc