Aula 004_005_006 - GO03301 PADRÕES ARQUITETURAIS

Prévia do material em texto

<p>GRADUAÇÃO</p><p>2024/1</p><p>Disciplina</p><p>GO03301 – PADRÕES ARQUITETURAIS</p><p>Prof. Esp. Rogério Mendes Vieira</p><p>rogerio.vieira@unialfa.com.br</p><p>Aula 04, 05 e 06 – Correção da N1 +</p><p>Case + Padrões Arquiteturais</p><p>mailto:rogerio.vieira@unialfa.com.br</p><p>Ementa</p><p>Ementa</p><p>Ementa</p><p>Autores/Capítulos</p><p>• Ian Sommerville, 9 ed.</p><p>Capítulos: 5, 6, 7</p><p>• Craig Larman, 3 ed.</p><p>Capítulos: 39, 37, 23, 26, 36</p><p>• Roger Pressman, 7 ed.</p><p>Capítulos: 8, 9</p><p>• Marco Túlio Valente</p><p>Capítulos: 6, 7</p><p>N1</p><p>Correção da N1</p><p>Correção da N1</p><p>Concorrência</p><p>Fluxo de dados</p><p>Deadlock</p><p>Lentidão</p><p>Stakeholders (cliente, analista de negócio,</p><p>desenvolvedores, implantadores, Product</p><p>Owner, DBA, analista de infraestrutura...).</p><p>Pipe</p><p>Camadas (2 camadas e 3 camadas)</p><p>MVC</p><p>Microsserviço</p><p>Mostra o funcionamento do sistema com um bom</p><p>nível de detalhes, possibilitando resolver</p><p>problemas de requisitos não funcionais.</p><p>Mostra os módulos do sistema, ou seja,</p><p>unidades de implementação e como se</p><p>relacionam entre si.</p><p>Correção da N1</p><p>Mostra os nós do sistema, ou seja, a</p><p>infraestrutura utilizada pelo sistema e</p><p>como o sistema será instalado.</p><p>Mostra o modelo de dados, seus</p><p>relacionamentos e fluxo de dados.</p><p>Apesar de você poder utilizar, é importante</p><p>considerar que o cliente é leigo. Então,</p><p>uma visão com menos detalhes seria mais</p><p>recomendável, como a visão de módulos.</p><p>1) Padronizar a documentação</p><p>(template/modelo)</p><p>2) Utilizar linguagem simples e objetiva</p><p>3) Evitar termos ou frases que gerem dúvidas</p><p>De interpretação</p><p>Correção da N1</p><p>Experiências alheias</p><p>Vida Real</p><p>Vida real</p><p>Hipsters – Paulo Silveira x Fábio Akita x Roberta Arcoverde</p><p>Vida real</p><p>Hipsters</p><p>https://www.hipsters.tech/clean-architeture-hipsters-ponto-tech-254/</p><p>https://www.hipsters.tech/erps-arquiteturas-e-totvs-hipsters-ponto-tech-141/</p><p>https://www.hipsters.tech/case-farfetch-front-end-hipsters-ponto-tech-311/</p><p>https://www.hipsters.tech/case-banco-pan-cloud-e-microsservicos-hipsters-ponto-tech-306/</p><p>PDV</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Background</p><p>Padrões/Estilos</p><p>Projeto PDV</p><p>Padrões/Estilos</p><p>Padrões/Estilos Arquiteturais</p><p>Padrões/Estilos</p><p>Padrões/Estilos</p><p>Padrão Arquitetural</p><p>• São soluções recorrentes para problemas arquiteturais específicos que surgem durante</p><p>o projeto e desenvolvimento de software.</p><p>• Fornece diretrizes e abstrações para organizar a estrutura de um sistema.</p><p>• Facilita a comunicação entre os membros da equipe.</p><p>• Promove a reutilização de boas práticas.</p><p>• Tem uma finalidade específica e pode ser aplicado em diferentes contextos para</p><p>resolver problemas comuns de arquitetura de software.</p><p>• Exemplos de padrões arquiteturais incluem o padrão MVC (Model-View-Controller), padrão</p><p>Repository, padrão Observer, entre outros.</p><p>Padrões/Estilos</p><p>Estilo Arquitetural</p><p>• É uma abstração mais ampla que descreve a organização geral de um sistema de</p><p>software, sem fornecer uma solução específica para problemas arquiteturais.</p><p>• Define os principais componentes e a interação entre eles, bem como os princípios</p><p>gerais de design que guiam a arquitetura do sistema.</p><p>• Apesar de definir uma estrutura geral para o sistema, permite variações na implementação</p><p>específica de acordo com os requisitos e restrições do projeto.</p><p>• Exemplos de estilos arquiteturais incluem arquitetura em camadas, arquitetura orientada a</p><p>serviços (SOA), arquitetura orientada a microsserviços, entre outros.</p><p>Padrões/Estilos</p><p>Diferenças entre Padrão Arquitetural e Estilo Arquitetural</p><p>• A principal diferença entre padrão arquitetural e estilo arquitetural está no nível de</p><p>detalhe e abstração.</p><p>• Um padrão arquitetural oferece uma solução concreta e detalhada para um problema</p><p>específico, enquanto um estilo arquitetural fornece uma visão mais ampla e abstrata da</p><p>organização geral do sistema.</p><p>Padrões/Estilos</p><p>Diagrama</p><p>Padrões/Estilos</p><p>Monolito</p><p>• Descreve um sistema de software em que todos os componentes e funcionalidades são</p><p>desenvolvidos e implantados como um único artefato (unidade coesa).</p><p>• Características:</p><p>• Centralização: Todas as funcionalidades e lógica de negócios são</p><p>implementadas dentro de um único código-base e implantadas como uma única</p><p>aplicação.</p><p>• Acoplamento: Os diferentes módulos e componentes do sistema estão</p><p>altamente acoplados, o que significa que as mudanças em uma parte do sistema</p><p>podem ter impacto em outras partes.</p><p>Padrões/Estilos</p><p>Monolito</p><p>• Características:</p><p>• Manutenção: Como todo o código está contido em um único código-base, a</p><p>manutenção do monolito pode se tornar desafiadora à medida que o sistema</p><p>cresce e se torna mais complexo.</p><p>• Dependências: Os componentes do monolito tendem a depender fortemente</p><p>uns dos outros, o que pode dificultar a reutilização de código e a introdução de</p><p>novas tecnologias.</p><p>Padrões/Estilos</p><p>Monolito</p><p>• Vantagens/Desvantagens:</p><p>• Simplicidade Inicial: Os monolitos são fáceis de desenvolver e implantar</p><p>inicialmente, pois não requerem uma infraestrutura complexa.</p><p>• Menos Complexidade de Implantação: A implantação de um monolito é</p><p>simples, pois envolve apenas a distribuição de um único artefato.</p><p>• Facilidade de Debugging: A depuração e o monitoramento de um monolito</p><p>podem ser mais fáceis, pois tudo está em um único lugar.</p><p>• Escalabilidade Limitada: Os monolitos podem ter dificuldade em escalar</p><p>horizontalmente para lidar com um grande volume de tráfego, devido ao</p><p>acoplamento entre os componentes.</p><p>Padrões/Estilos</p><p>Monolito</p><p>• Vantagens/Desvantagens:</p><p>• Barreira Tecnológica: A introdução de novas tecnologias ou atualizações de</p><p>componentes pode ser difícil, pois tudo está integrado em um único código-base.</p><p>Padrões/Estilos</p><p>Monolito</p><p>Padrões/Estilos</p><p>Pipes and Filters</p><p>• Descreve um sistema composto por uma série de componentes independentes (filtros) que</p><p>processam dados de entrada e geram dados de saída. São conectados por meio de tubos</p><p>(pipes), que encaminham os dados de um filtro para outro. É organizado de forma linear,</p><p>com os dados fluindo através dos filtros em uma ordem específica.</p><p>• Características:</p><p>• Componentes Independentes: Cada filtro é um componente independente que</p><p>realiza uma tarefa específica de processamento de dados.</p><p>• Composição Linear: Os filtros são organizados em uma sequência linear, onde</p><p>os dados fluem de um filtro para o próximo por meio de tubos.</p><p>Padrões/Estilos</p><p>Pipes and Filters</p><p>• Características:</p><p>Dados Passivos: Os dados são passivamente processados pelos filtros à medida</p><p>que fluem através do sistema.</p><p>• Vantagens/Desvantagens:</p><p>Modularidade: Os filtros são componentes independentes e modulares, o que</p><p>facilita a criação, manutenção e reutilização de funcionalidades específicas.</p><p>Flexibilidade: O sistema pode ser facilmente expandido ou modificado adicionando</p><p>ou removendo filtros sem afetar outros componentes do sistema.</p><p>Reutilização de Componentes: Os filtros podem ser reutilizados em diferentes</p><p>contextos ou em sistemas diferentes, desde que cumpram a mesma função.</p><p>Padrões/Estilos</p><p>Pipes and Filters</p><p>• Vantagens/Desvantagens :</p><p>• Overhead de Comunicação: O fluxo de dados através dos tubos pode resultar</p><p>em overhead de comunicação, especialmente se muitos filtros estiverem</p><p>conectados em sequência.</p><p>• Dificuldade em Lidar com Dados Estado-dependentes: O padrão é mais</p><p>adequado para processamento de dados sem estado, tornando-se menos eficaz</p><p>quando os filtros precisam manter informações de estado entre as operações.</p><p>• Dificuldade em Modelar Fluxos Complexos: O padrão pode ser limitado ao</p><p>lidar com fluxos de dados complexos que exigem lógica de controle mais</p><p>sofisticada do que uma simples sequência linear de filtros.</p><p>Padrões/Estilos</p><p>Pipes and Filters</p><p>Padrões/Estilos</p><p>Tier x Layer</p><p>• São frequentemente usados para descrever a organização e a estruturação de um</p><p>sistema, mas eles têm</p><p>significados ligeiramente diferentes</p><p>• Tier (Nível ou Camada Física):</p><p>• Refere-se a uma divisão física de um sistema distribuído, onde cada tier é</p><p>implantado em uma camada separada (física ou lógica) de hardware ou software.</p><p>• Layer (Camada):</p><p>• Refere-se a uma divisão lógica de responsabilidades dentro de um sistema.</p><p>Cada camada contém um conjunto de funcionalidades relacionadas e tem uma</p><p>interface bem definida com outras camadas adjacentes. As camadas são</p><p>organizadas hierarquicamente, com camadas mais baixas fornecendo serviços</p><p>para as camadas superiores.</p><p>Padrões/Estilos</p><p>Camadas</p><p>• É um padrão arquitetural que organiza um sistema de software em camadas distintas,</p><p>onde cada camada tem uma responsabilidade específica e comunica-se apenas com</p><p>camadas adjacentes.</p><p>• Características:</p><p>• Separação de Responsabilidades: O sistema é dividido em camadas lógicas,</p><p>cada uma responsável por um aspecto específico da aplicação, como</p><p>apresentação, lógica de negócios e acesso a dados.</p><p>• Hierarquia de Dependência: As camadas são organizadas em uma hierarquia,</p><p>com as camadas superiores dependendo das camadas inferiores, mas não vice-</p><p>versa. Por exemplo, a camada de apresentação pode depender da camada de</p><p>lógica de negócios, que por sua vez depende da camada de acesso a dados.</p><p>Padrões/Estilos</p><p>Camadas</p><p>• Características:</p><p>• Separação de Responsabilidades: O sistema é dividido em camadas lógicas,</p><p>cada uma responsável por um aspecto específico da aplicação, como</p><p>apresentação, lógica de negócios e acesso a dados.</p><p>• Modularidade: A arquitetura em camadas promove a modularidade do sistema,</p><p>permitindo que as diferentes camadas sejam desenvolvidas, testadas e mantidas</p><p>de forma independente umas das outras.</p><p>Padrões/Estilos</p><p>Camadas</p><p>• Vantagens/Desvantagens:</p><p>• Separação de Responsabilidades: Cada camada tem uma responsabilidade</p><p>clara e definida, facilitando o entendimento e a manutenção do sistema.</p><p>• Reutilização de Componentes: A modularidade das camadas permite a</p><p>reutilização de componentes em diferentes partes do sistema.</p><p>• Facilidade de Teste: As camadas separadas podem ser testadas de forma</p><p>isolada, facilitando o teste automatizado e a detecção de falhas.</p><p>• Overhead de Comunicação: A comunicação entre as camadas pode introduzir</p><p>overhead, especialmente em sistemas distribuídos.</p><p>• Rigidez: A estrutura em camadas pode ser rígida e dificultar a introdução de</p><p>mudanças significativas na arquitetura do sistema.</p><p>Padrões/Estilos</p><p>Camadas</p><p>• Vantagens/Desvantagens:</p><p>• Complexidade Adicional: A introdução de várias camadas pode aumentar a</p><p>complexidade do sistema e exigir uma gestão cuidadosa das dependências entre</p><p>as camadas.</p><p>Padrões/Estilos</p><p>Duas camadas (Server-Side)</p><p>• Também conhecida como arquitetura cliente-servidor, é um padrão arquitetural que</p><p>organiza um sistema de software em duas camadas distintas: a camada de apresentação</p><p>e a camada de dados.</p><p>• Características:</p><p>• Divisão em Camadas: O sistema é dividido em duas camadas principais: a</p><p>camada de apresentação, responsável pela interface com o usuário, e a camada</p><p>de dados, responsável pelo armazenamento e manipulação dos dados.</p><p>• Comunicação Cliente-Servidor: A camada de apresentação (cliente) interage</p><p>com a camada de dados (servidor) por meio de solicitações e respostas.</p><p>Padrões/Estilos</p><p>Duas camadas (Server-Side)</p><p>• Características:</p><p>• Acoplamento Direto: A camada de apresentação tem acesso direto aos dados</p><p>na camada de dados, geralmente por meio de chamadas de API ou consultas</p><p>diretas ao banco de dados.</p><p>• Simplicidade: A arquitetura em duas camadas é relativamente simples de</p><p>entender e implementar, tornando-a adequada para sistemas pequenos e</p><p>médios.</p><p>Padrões/Estilos</p><p>Duas camadas (Server-Side)</p><p>• Vantagens/Desvantagens:</p><p>• Simplicidade: A arquitetura em duas camadas é fácil de entender e implementar,</p><p>especialmente para sistemas pequenos e médios.</p><p>• Baixa Latência: Como não há intermediação entre a camada de apresentação e</p><p>a camada de dados, a latência das operações é geralmente baixa.</p><p>• Facilidade de Manutenção: A divisão clara entre a camada de apresentação e a</p><p>camada de dados facilita a manutenção e o teste do sistema.</p><p>• Acoplamento Direto: A comunicação direta entre a camada de apresentação e a</p><p>camada de dados pode levar a um acoplamento rígido, dificultando a reutilização</p><p>e a manutenção do código.</p><p>Padrões/Estilos</p><p>Duas camadas (Server-Side)</p><p>• Vantagens/Desvantagens:</p><p>• Escalabilidade Limitada: A arquitetura em duas camadas pode ter dificuldade</p><p>em escalar para lidar com um grande volume de tráfego, especialmente em</p><p>sistemas distribuídos.</p><p>• Segurança: A exposição direta da camada de dados à camada de apresentação</p><p>pode representar riscos de segurança, como ataques de injeção de SQL.</p><p>Padrões/Estilos</p><p>Duas camadas (Server-Side)</p><p>Padrões/Estilos</p><p>Três camadas</p><p>• A arquitetura em três camadas é um padrão arquitetural que organiza um sistema de</p><p>software em três camadas distintas: a camada de apresentação, a camada de lógica de</p><p>negócios e a camada de acesso a dados.</p><p>• Características:</p><p>• Separação de Responsabilidades: O sistema é dividido em três camadas</p><p>lógicas, cada uma com uma responsabilidade específica. A camada de</p><p>apresentação é responsável por interagir com o usuário final, a camada de lógica</p><p>de negócios implementa a lógica de processamento do sistema e a camada de</p><p>acesso a dados lida com a persistência dos dados.</p><p>Padrões/Estilos</p><p>Três camadas</p><p>• Características:</p><p>• Hierarquia de Dependência: As camadas são organizadas em uma hierarquia,</p><p>com a camada de apresentação dependendo da camada de lógica de negócios,</p><p>que por sua vez depende da camada de acesso a dados. Isso promove um baixo</p><p>acoplamento entre as camadas.</p><p>• Comunicação Estruturada: A comunicação entre as camadas ocorre de forma</p><p>estruturada, geralmente por meio de interfaces ou contratos bem definidos. Isso</p><p>permite que as camadas se comuniquem de forma independente e modular.</p><p>• Modularidade: A arquitetura em três camadas promove a modularidade do</p><p>sistema, permitindo que cada camada seja desenvolvida, testada e mantida de</p><p>forma independente uma da outra.</p><p>Padrões/Estilos</p><p>Três camadas</p><p>• Vantagens/Desvantagens:</p><p>• Separação de Responsabilidades: Cada camada tem uma responsabilidade</p><p>clara e definida, facilitando a compreensão e a manutenção do sistema.</p><p>• Reutilização de Componentes: A modularidade das camadas permite a</p><p>reutilização de componentes em diferentes partes do sistema.</p><p>• Facilidade de Teste: As camadas separadas podem ser testadas de forma</p><p>isolada, facilitando o teste automatizado e a detecção de falhas.</p><p>• Complexidade Adicional: A introdução de várias camadas pode aumentar a</p><p>complexidade do sistema e exigir uma gestão cuidadosa das dependências entre</p><p>as camadas.</p><p>Padrões/Estilos</p><p>Três camadas</p><p>• Vantagens/Desvantagens:</p><p>• Overhead de Comunicação: A comunicação entre as camadas pode introduzir</p><p>overhead, especialmente em sistemas distribuídos.</p><p>• Rigidez da Arquitetura: A estrutura em três camadas pode ser rígida e dificultar</p><p>a introdução de mudanças significativas na arquitetura do sistema.</p><p>Padrões/Estilos</p><p>Três camadas</p><p>Padrões/Estilos</p><p>Três camadas</p><p>Padrões/Estilos</p><p>Três camadas</p><p>Padrões/Estilos</p><p>MVC (Model-View-Controller)</p><p>• É um dos padrões mais populares e amplamente adotados. Separa a aplicação em três</p><p>componentes principais: o Modelo (Model), a Visão (View) e o Controlador (Controller).</p><p>• Características:</p><p>• Flexibilidade na Interface do Usuário: Permite que a interface do usuário</p><p>(View) seja facilmente alterada ou substituída sem afetar o modelo subjacente ou</p><p>a lógica de controle.</p><p>• Extensibilidade: Facilita a adição de novas funcionalidades à aplicação sem a</p><p>necessidade de modificar componentes existentes.</p><p>• Padronização do Desenvolvimento: Fornece uma estrutura bem definida para</p><p>o desenvolvimento de aplicações, o que pode facilitar a colaboração entre os</p><p>membros da equipe e garantir consistência no código.</p><p>Padrões/Estilos</p><p>MVC (Model-View-Controller)</p><p>• Vantagens/Desvantagens:</p><p>• Separação de Preocupações: Promove uma clara separação de preocupações,</p><p>facilitando a manutenção e o desenvolvimento modular da aplicação.</p><p>• Reutilização de Componentes: Os componentes do modelo, visão e</p><p>controlador podem ser reutilizados em diferentes partes da aplicação ou em</p><p>diferentes projetos.</p><p>• Facilidade de Teste: A separação do modelo, visão e controlador facilita o teste</p><p>unitário de cada componente individualmente, melhorando a qualidade e a</p><p>robustez da aplicação.</p><p>Padrões/Estilos</p><p>MVC (Model-View-Controller)</p><p>• Vantagens/Desvantagens:</p><p>• Complexidade Adicional: A implementação do padrão MVC pode introduzir</p><p>alguma complexidade adicional, especialmente para aplicativos pequenos ou</p><p>simples.</p><p>• Curva de Aprendizado: Para desenvolvedores menos experientes, pode haver</p><p>uma curva de aprendizado ao entender e trabalhar com a estrutura MVC e suas</p><p>interações.</p><p>• Sobrecarga de Comunicação: Em alguns casos, pode haver uma sobrecarga</p><p>de comunicação entre o modelo, visão e controlador, especialmente em</p><p>aplicações muito grandes ou complexas.</p><p>Padrões/Estilos</p><p>MVC (Model-View-Controller)</p><p>Padrões/Estilos</p><p>MVVM (Model-View-View-Model)</p><p>• Foi introduzido pela Microsoft. É um padrão amplamente utilizado em aplicativos de</p><p>interface de usuário, como aplicações web e móveis.</p><p>• Características:</p><p>• Binding Bidirecional de Dados: facilita a ligação bidirecional de dados entre a</p><p>visão e o ViewModel. Isso significa que as alterações feitas na interface do</p><p>usuário são refletidas automaticamente no ViewModel e vice-versa, sem a</p><p>necessidade de código adicional para sincronizar os dados.</p><p>• Abstração da Lógica de Apresentação: encapsula a lógica de apresentação da</p><p>interface do usuário, permitindo que os desenvolvedores se concentrem na</p><p>manipulação dos dados e na interação do usuário, sem se preocupar com a</p><p>implementação detalhada da interface do usuário.</p><p>Padrões/Estilos</p><p>MVVM (Model-View-View-Model)</p><p>• Características:</p><p>• Flexibilidade de Implementação: não é específico para uma plataforma ou</p><p>tecnologia de desenvolvimento em particular. Ele pode ser implementado em</p><p>uma variedade de ambientes, incluindo aplicativos da web, aplicativos móveis e</p><p>aplicativos de desktop, usando diferentes frameworks e linguagens de</p><p>programação.</p><p>• Vantagens/Desvantagens:</p><p>• Separação de Preocupações: O padrão MVVM promove uma clara separação</p><p>de preocupações, facilitando a manutenção e o desenvolvimento modular da</p><p>aplicação.</p><p>Padrões/Estilos</p><p>MVVM (Model-View-View-Model)</p><p>• Vantagens/Desvantagens:</p><p>• Reutilização de Componentes: Os ViewModels podem ser reutilizados em</p><p>diferentes partes da aplicação ou em diferentes projetos, proporcionando uma</p><p>melhor modularidade e flexibilidade.</p><p>• Testabilidade: A separação entre a visão e o ViewModel torna mais fácil testar a</p><p>lógica de apresentação da interface do usuário sem a necessidade de interação</p><p>com a interface gráfica real.</p><p>• Curva de Aprendizado: Para desenvolvedores menos familiarizados com o</p><p>padrão MVVM, pode haver uma curva de aprendizado inicial ao entender e</p><p>trabalhar com a estrutura do padrão.</p><p>Padrões/Estilos</p><p>MVVM (Model-View-View-Model)</p><p>• Vantagens/Desvantagens:</p><p>• Complexidade Adicional: pode introduzir alguma complexidade adicional,</p><p>especialmente para aplicativos pequenos ou simples.</p><p>• Overhead de Desenvolvimento: O padrão MVVM pode exigir mais código e</p><p>estruturação adicional em comparação com abordagens mais simples, como</p><p>code-behind.</p><p>Padrões/Estilos</p><p>MVVM (Model-View-View-Model)</p><p>Padrões/Estilos</p><p>Repository</p><p>• Utilizado para separar a lógica de acesso a dados do restante da aplicação. Fornece uma</p><p>camada de abstração entre a lógica de negócios da aplicação e a fonte de dados, como</p><p>um banco de dados, serviço web ou API externa.</p><p>• Características:</p><p>• Abstração de Acesso a Dados: Repository encapsula a lógica de acesso a</p><p>dados, fornecendo uma interface comum para interagir com os dados</p><p>subjacentes. Isso permite que a lógica de negócios da aplicação trabalhe com</p><p>objetos de domínio sem se preocupar com os detalhes de como os dados são</p><p>armazenados e recuperados.</p><p>• Centralização da Lógica de Acesso a Dados: centraliza toda a lógica de</p><p>acesso a dados em um único local na aplicação, facilitando a manutenção e</p><p>evolução do código relacionado ao acesso a dados.</p><p>Padrões/Estilos</p><p>Repository</p><p>• Características:</p><p>• Flexibilidade: permite que diferentes implementações de acesso a dados sejam</p><p>facilmente substituídas ou trocadas sem afetar a lógica de negócios da aplicação.</p><p>Isso pode ser útil ao mudar de um banco de dados para outro, por exemplo, sem</p><p>alterar o código que depende do Repository.</p><p>• Vantagens/Desvantagens:</p><p>• Manutenibilidade: Ao centralizar toda a lógica de acesso a dados em um único</p><p>local, o padrão Repository torna mais fácil entender, modificar e manter o código</p><p>relacionado ao acesso a dados.</p><p>• Desacoplamento: desacopla a lógica de negócios da aplicação da fonte de</p><p>dados subjacente, permitindo que essas duas partes da aplicação evoluam</p><p>independentemente uma da outra.</p><p>Padrões/Estilos</p><p>Repository</p><p>• Vantagens/Desvantagens:</p><p>• Complexidade Adicional: A introdução de uma camada de abstração adicional</p><p>(o Repository) pode aumentar a complexidade do código, especialmente em</p><p>aplicativos pequenos ou simples.</p><p>• Overhead de Implementação: O padrão pode exigir um esforço adicional de</p><p>implementação para criar e manter as interfaces e implementações.</p><p>• Possível Perda de Desempenho: Dependendo da implementação, pode haver</p><p>um pequeno impacto no desempenho da aplicação devido à sobrecarga de</p><p>abstração adicionada pela camada Repository.</p><p>Padrões/Estilos</p><p>Repository</p><p>Padrões/Estilos</p><p>Repository</p><p>Padrões/Estilos</p><p>SOA</p><p>• SOA, ou Arquitetura Orientada a Serviços, é um paradigma arquitetural para</p><p>desenvolvimento de sistemas de software que promove a organização de funcionalidades</p><p>em serviços independentes e interconectados.</p><p>• Características:</p><p>• Serviços: Funcionalidades de negócio são expostas como serviços</p><p>independentes e autônomos, acessíveis por meio de interfaces padronizadas.</p><p>• Interoperabilidade: Os serviços podem ser desenvolvidos em diferentes</p><p>tecnologias e linguagens de programação, permitindo a interoperabilidade entre</p><p>sistemas heterogêneos.</p><p>• Flexibilidade e Adaptabilidade: O padrão SOA permite que sistemas sejam</p><p>facilmente adaptados e reconfigurados para atender às necessidades de negócio</p><p>em constante mudança.</p><p>Padrões/Estilos</p><p>SOA</p><p>• Vantagens/Desvantagens :</p><p>• Reutilização de Serviços: Os serviços podem ser reutilizados em diferentes</p><p>aplicativos e contextos, economizando tempo e esforço de desenvolvimento.</p><p>• Escalabilidade: Os serviços podem ser escalados independentemente,</p><p>permitindo que partes específicas do sistema sejam dimensionadas conforme</p><p>necessário para atender à demanda.</p><p>• Padronização e Consistência: SOA promove a padronização e a consistência</p><p>no desenvolvimento de software, facilitando a manutenção e evolução dos</p><p>sistemas ao longo do tempo.</p><p>Padrões/Estilos</p><p>SOA</p><p>• Vantagens/Desvantagens:</p><p>• Complexidade: A implementação de uma arquitetura SOA pode introduzir</p><p>complexidade adicional devido à necessidade de gerenciar e orquestrar vários</p><p>serviços e suas interações.</p><p>• Overhead de Comunicação: A comunicação entre serviços pode introduzir um</p><p>overhead significativo, especialmente em ambientes distribuídos, afetando o</p><p>desempenho do sistema.</p><p>• Gerenciamento de Versões: Gerenciar as versões dos serviços pode ser</p><p>desafiador, especialmente quando há dependências entre diferentes versões de</p><p>serviços.</p><p>Padrões/Estilos</p><p>SOA</p><p>Padrões/Estilos</p><p>Queue</p><p>• O padrão arquitetural Queue, ou fila, é uma abordagem comum para a comunicação</p><p>assíncrona entre componentes de um sistema distribuído. Neste padrão, as</p><p>mensagens são colocadas em uma fila por um produtor e posteriormente consumidas por</p><p>um consumidor. As filas podem ser implementadas em sistemas de mensagens, como</p><p>RabbitMQ, Apache Kafka ou Amazon SQS, ou em sistemas de banco de dados que</p><p>oferecem</p><p>suporte a filas.</p><p>• Características:</p><p>• Assincronia: O padrão Queue permite a comunicação assíncrona entre</p><p>componentes do sistema, o que significa que o produtor não precisa esperar pela</p><p>resposta do consumidor para continuar seu trabalho.</p><p>Padrões/Estilos</p><p>Queue</p><p>• Características:</p><p>• Desacoplamento: Os produtores e consumidores não precisam estar cientes um</p><p>do outro. Eles interagem apenas por meio da fila, o que promove o</p><p>desacoplamento e a independência entre os componentes.</p><p>• Escalabilidade: As filas podem lidar com grandes volumes de mensagens e</p><p>escalonar horizontalmente para atender à demanda crescente.</p><p>• Persistência: Muitas implementações de filas oferecem suporte à persistência</p><p>de mensagens, o que significa que as mensagens não serão perdidas em caso</p><p>de falha do sistema.</p><p>Padrões/Estilos</p><p>Queue</p><p>• Vantagens/Desvantagens:</p><p>• Resiliência: As filas podem fornecer um buffer entre produtores e consumidores,</p><p>ajudando a proteger o sistema contra sobrecargas e falhas temporárias.</p><p>• Flexibilidade: As filas podem ser usadas para uma variedade de casos de uso,</p><p>como processamento de pedidos assíncrono, comunicação entre microserviços,</p><p>distribuição de tarefas em sistemas de processamento em lote, entre outros.</p><p>• Complexidade de Gerenciamento: A implementação e o gerenciamento de filas</p><p>podem adicionar complexidade ao sistema, especialmente em ambientes</p><p>distribuídos com múltiplas filas e consumidores.</p><p>Padrões/Estilos</p><p>Queue</p><p>• Vantagens/Desvantagens:</p><p>• Latência: A comunicação assíncrona introduz latência adicional, especialmente</p><p>em casos onde a mensagem precisa passar por várias etapas de processamento</p><p>antes de ser consumida.</p><p>Padrões/Estilos</p><p>Queue</p><p>Padrões/Estilos</p><p>Publish-Subscribe</p><p>• É um modelo de comunicação entre componentes de um sistema distribuído, onde os</p><p>remetentes de mensagens, ou publicadores (publishers), não são diretamente acoplados</p><p>aos destinatários de mensagens, ou assinantes (subscribers). Em vez disso, os</p><p>publicadores publicam mensagens em canais ou tópicos, e os assinantes se inscrevem</p><p>nesses canais para receber as mensagens relevantes.</p><p>• Características:</p><p>• Padrão de Mensagens: O Pub/Sub geralmente segue um padrão de</p><p>mensagens, onde as mensagens são encapsuladas e podem conter informações</p><p>estruturadas ou não estruturadas.</p><p>Padrões/Estilos</p><p>Publish-Subscribe</p><p>• Características:</p><p>• Padrão de Mensagens: O Pub/Sub geralmente segue um padrão de</p><p>mensagens, onde as mensagens são encapsuladas e podem conter informações</p><p>estruturadas ou não estruturadas.</p><p>• Flexibilidade: Os canais de comunicação podem ser dinamicamente criados e</p><p>destruídos conforme necessário, facilitando a adição e remoção de componentes</p><p>do sistema.</p><p>• Escalabilidade: O padrão Pub/Sub é altamente escalável, permitindo que um</p><p>grande número de publicadores e assinantes se comuniquem de forma eficiente.</p><p>Padrões/Estilos</p><p>Publish-Subscribe</p><p>• Vantagens/Desvantagens:</p><p>• Escalabilidade Horizontal: O padrão Pub/Sub é altamente escalável, permitindo</p><p>que sistemas cresçam sem aumentar a complexidade ou sobrecarregar os</p><p>componentes existentes.</p><p>• Distribuição Geográfica: O Pub/Sub é adequado para sistemas distribuídos em</p><p>larga escala, permitindo que os componentes do sistema estejam</p><p>geograficamente dispersos.</p><p>• Complexidade de Implementação: A implementação de um sistema Pub/Sub</p><p>pode ser mais complexa do que outros modelos de comunicação mais diretos,</p><p>especialmente em ambientes distribuídos.</p><p>Padrões/Estilos</p><p>Publish-Subscribe</p><p>• Vantagens/Desvantagens:</p><p>• Garantia de Entrega: O padrão Pub/Sub não garante a entrega de mensagens,</p><p>o que pode ser um problema em alguns cenários onde a entrega de mensagens</p><p>é crítica.</p><p>Padrões/Estilos</p><p>Publish-Subscribe</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>• É uma abordagem de desenvolvimento de software que consiste em dividir uma</p><p>aplicação em um conjunto de serviços independentes, cada um executando um</p><p>processo específico e comunicando-se com outros serviços por meio de interfaces bem</p><p>definidas. Cada serviço é construído em torno de uma única funcionalidade de negócio</p><p>e pode ser desenvolvido, implantado e escalado de forma independente.</p><p>• Características:</p><p>• Decomposição de Funcionalidades: A aplicação é dividida em serviços</p><p>individuais, cada um responsável por uma única funcionalidade ou processo de</p><p>negócio.</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>• Características:</p><p>• Comunicação via API: Os serviços se comunicam uns com os outros por meio</p><p>de interfaces de programação de aplicativos (APIs), geralmente usando</p><p>protocolos de comunicação como HTTP/REST ou gRPC.</p><p>• Escalabilidade Independente: Cada serviço pode ser escalado</p><p>independentemente de outros serviços, permitindo uma maior flexibilidade e</p><p>eficiência na utilização de recursos.</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>• Vantagens/Desvantagens:</p><p>• Resiliência e Tolerância a Falhas: O padrão de microsserviços promove a</p><p>resiliência e a tolerância a falhas, uma vez que uma falha em um serviço não</p><p>afeta necessariamente o funcionamento de outros serviços.</p><p>• Facilidade de Manutenção e Atualização: Como cada serviço é independente,</p><p>é mais fácil fazer alterações em partes específicas da aplicação sem afetar</p><p>outras partes.</p><p>• Tecnologias Diversificadas: Os microsserviços permitem que diferentes</p><p>tecnologias sejam usadas para diferentes partes da aplicação, permitindo</p><p>escolher a melhor tecnologia para cada caso de uso.</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>• Vantagens/Desvantagens:</p><p>• Complexidade da Arquitetura: Gerenciar um grande número de microsserviços</p><p>pode aumentar a complexidade da arquitetura e a sobrecarga de comunicação</p><p>entre os serviços..</p><p>• Coordenação entre Serviços: À medida que o número de microsserviços</p><p>aumenta, pode ser necessário implementar uma lógica adicional de coordenação</p><p>e controle entre os serviços.</p><p>• Desafios de Implantação e Monitoramento: Gerenciar e implantar um grande</p><p>número de microsserviços pode ser complexo, especialmente quando se trata de</p><p>garantir a consistência e o monitoramento adequado de todos os serviços.</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>Padrões/Estilos</p><p>Microsserviços</p><p>Dúvidas</p><p>Slide 1</p><p>Slide 2</p><p>Slide 3</p><p>Slide 4</p><p>Slide 5</p><p>Slide 6</p><p>Slide 7</p><p>Slide 8</p><p>Slide 9</p><p>Slide 10</p><p>Slide 11</p><p>Slide 12</p><p>Slide 13</p><p>Slide 14</p><p>Slide 15</p><p>Slide 16</p><p>Slide 17</p><p>Slide 18</p><p>Slide 19</p><p>Slide 20</p><p>Slide 21</p><p>Slide 22</p><p>Slide 23</p><p>Slide 24</p><p>Slide 25</p><p>Slide 26</p><p>Slide 27</p><p>Slide 28</p><p>Slide 29</p><p>Slide 30</p><p>Slide 31</p><p>Slide 32</p><p>Slide 33</p><p>Slide 34</p><p>Slide 35</p><p>Slide 36</p><p>Slide 37</p><p>Slide 38</p><p>Slide 39</p><p>Slide 40</p><p>Slide 41</p><p>Slide 42</p><p>Slide 43</p><p>Slide 44</p><p>Slide 45</p><p>Slide 46</p><p>Slide 47</p><p>Slide 48</p><p>Slide 49</p><p>Slide 50</p><p>Slide 51</p><p>Slide 52</p><p>Slide 53</p><p>Slide 54</p><p>Slide 55</p><p>Slide 56</p><p>Slide 57</p><p>Slide 58</p><p>Slide 59</p><p>Slide 60</p><p>Slide 61</p><p>Slide 62</p><p>Slide 63</p><p>Slide 64</p><p>Slide 65</p><p>Slide 66</p><p>Slide 67</p><p>Slide 68</p><p>Slide 69</p><p>Slide 70</p><p>Slide 71</p><p>Slide 72</p><p>Slide 73</p><p>Slide 74</p><p>Slide 75</p><p>Slide 76</p><p>Slide 77</p><p>Slide 78</p><p>Slide 79</p><p>Slide 80</p><p>Slide 81</p><p>Slide 82</p><p>Slide 83</p><p>Slide 84</p><p>Slide 85</p><p>Slide 86</p><p>Slide 87</p><p>Slide 88</p><p>Slide 89</p><p>Slide 90</p><p>Slide 91</p><p>Slide 92</p><p>Slide 93</p><p>Slide 94</p><p>Slide 95</p><p>Slide 96</p><p>Slide 97</p><p>Slide 98</p><p>Slide 99</p><p>Slide 100</p><p>Slide 101</p>