Fundamentos de arquitetura de software 

Talysson @talyssonoc beacons.ai/talyssonoc Codeminer42 

O que é, e o que não é? Arquitetura de software 

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 é? 

Estilos de arquitetura, Padrões arquiteturais e Padrões de projeto Qual a diferença? 

Em camadas Pipeline ⋯ Microservices Event-driven Microfrontends ⋯ Monolítica Distribuída Topologia Estilo de arquitetura (Conjunto de trade-offs) 

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 

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 

O que são? Onde vivem? Responsabilidades 

“ Responsabilidade: uma obrigação de realizar uma tarefa ou saber uma informação "Object Design", Rebecca Wirfs-Brock e Alan McKean 

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 

7 

3 

Separation of Concerns (SoC) & Single Responsibility Principle (SRP) Atribuição de responsabilidades 

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 

No content

No content

X Fere o Single Responsibility Principle 

No content

X Fere Separation of Concerns 

Fere Separation of Concerns X Fere o Single Responsibility Principle X 

✓ ✓ 

{ 1 1 1 Fluxo da aplicação Regras e validações de domínio Banco de dados Exemplo de decisão de design 

Algumas responsabilidades são mais importantes que as outras Níveis de responsabilidades 

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 

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 

Níveis de responsabilidade Domínio Casos de uso (aplicação) Entrada & Saída (infraestrutura) > > 

Dependency Inversion Principle (DIP) & Dependency Injection (DI) Fluxo de dependências vs fluxo de dados 

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) 

A B Fluxo de dados Mais importante Menos importante Depende de 

A B Mais importante Menos importante Fluxo de dependência Fluxo de dados 

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 

CreateUser UserModel Fluxo de dados Depende de 

CreateUser UserModel Fluxo de dados UserRepository Depende de Implementa CreateUser nem sabe que UserModel existe Ambos dependem da interface UserRepository 

Injeção de dependência (Dependency Injection) { Exemplo de decisão de design 

Características de sucesso do sistema Impactadas por decisões da arquitetura 

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 

Seu time conhece e planeja a arquitetura do projeto? Problema: Arquitetura por implicação 

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 

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 

- 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 

Obrigado! @talyssonoc beacons.ai/talyssonoc