Arquitetura de Software: A diferença entre Arquitetura e Design

#ptbr #webdev #architecture #beginners

Créditos Imagens [Imagem 1, Imagem 2]

Muitas pessoas realmente não sabem a diferença entre arquitetura de software e design de software. Mesmo para desenvolvedores, a linha geralmente é embaçada e eles podem misturar elementos de padrões de arquitetura de software e padrões de design. Como desenvolvedor, gostaria de simplificar esses conceitos e explicar as diferenças entre design de software e arquitetura de software. Além disso, mostrarei por que é importante que um desenvolvedor saiba um pouco sobre arquitetura de software e muito sobre design de software. Então vamos começar.

A definição de arquitetura de software

Em palavras simples, arquitetura de software é o processo de converter características de software como flexibilidade, escalabilidade, viabilidade, reutilização e segurança em uma solução estruturada que atenda às expectativas técnicas e de negócios.Essa definição nos leva a perguntar sobre as características de um software que pode afetar o design de uma arquitetura de software. Há uma longa lista de características que representam principalmente os requisitos comerciais ou operacionais, além dos requisitos técnicos.

As características da arquitetura de software

Conforme explicado, as características do software descrevem os requisitos e as expectativas de um software nos níveis operacional e técnico. Assim, quando um líder de produto diz que está competindo em um mercado de rápida mudança e deve adaptar seu modelo de negócios rapidamente. O software deve ser "extensível, modular e de manutenção adequada" se uma empresa lidar com solicitações urgentes que precisam ser concluídas com êxito em questão de tempo. Como arquiteto de software, observe que o desempenho e a baixa tolerância a falhas, escalabilidade e confiabilidade são suas principais características. Agora, depois de definir as características anteriores, o proprietário da empresa informa que eles têm um orçamento limitado para esse projeto, outra característica aparece aqui, que é "a viabilidade".

Aqui você pode encontrar uma lista completa de características de software, também conhecidas como "atributos de qualidade".

Padrões de arquitetura de software

A maioria das pessoas provavelmente já ouviu falar do termo "MicroServices" antes. O MicroServices é um dos muitos outros padrões de arquitetura de software, como padrão em camadas, padrão orientado a eventos, padrão serverless e muitos mais. Alguns deles serão discutidos mais adiante neste artigo. O padrão de micros-serviços ganhou reputação após ser adotado pela Amazon e Netflix e mostrar seu grande impacto. Agora, vamos nos aprofundar nos padrões de arquitetura.

Uma observação rápida: não misture padrões de design como Factory ou Adaptors com padrões de arquitetura. Vou discuti-los mais tarde.

Arquitetura serverless

Essa arquitetura refere-se à solução de aplicativo que depende de serviços de terceiros para gerenciar a complexidade dos servidores e o gerenciamento de back-end. Arquitetura serverless é dividida em duas categorias principais. O primeiro é "Back-end como serviço (BaaS)" e o segundo é "Funções como serviço (FaaS)". A arquitetura sem servidor ajudará você a economizar muito tempo cuidando e corrigindo erros nas tarefas regulares de implantação e servidores.
O provedor mais famoso de API sem servidor é o Amazon AWS "Lambda".

Você pode ler mais sobre isso aqui.

Arquitetura orientada a eventos

Essa arquitetura depende de produtores e consumidores de eventos. A idéia principal é desacoplar as partes do sistema e cada parte será acionada quando um evento interessante de outra parte for acionado. É complicado? Vamos simplificar. Suponha que você crie um sistema de loja online e ele tenha duas partes. Um módulo de compra e um módulo de fornecedor. Se um cliente fizer uma compra, o módulo de compra geraria um evento "orderPending". Como o módulo do fornecedor é interessado no evento "orderPending", ele estará ouvindo, caso um evento desse seja acionado. Quando o módulo do fornecedor obtiver esse evento, ele executará algumas tarefas ou talvez acionará outro evento para solicitar mais do produto a um determinado fornecedor.

Lembre-se de que o produtor do evento não sabe qual consumidor do evento está ouvindo qual evento. Além disso, outros consumidores não sabem quais deles ouvem quais eventos. Portanto, a idéia principal é dissociar as partes do sistema.

Se você estiver interessado em aprender mais sobre isso, clique aqui.

Arquitetura de micros-serviços

A arquitetura de micros-serviços se tornou a arquitetura mais popular nos últimos anos. Depende do desenvolvimento de serviços modulares pequenos e independentes, em que cada serviço resolve um problema específico ou executa uma tarefa exclusiva e esses módulos se comunicam por meio de uma API bem definida para atender à meta de negócios. Eu não tenho que explicar mais, basta olhar para esta imagem.

Design de software

Enquanto a arquitetura do software é responsável pelo esqueleto e pela infraestrutura de alto nível de um software, o design do software é responsável pelo design do nível de código, como o que cada módulo está fazendo, o escopo das classes e os objetivos das funções, etc.

Se você é um desenvolvedor, é importante que você saiba qual é o princípio do SOLID e como um padrão de design deve resolver problemas regulares.

SOLID refere-se aos princípios: Single Responsibility, ‌Open Closed, ‌Liskov substitution, ‌Interface Segregation e D‌
ependency **Inversion**

‌Single Responsibility Principle: Significa que cada classe deve ter um único objetivo, uma responsabilidade e um motivo para mudar.
‌Open Closed Principle: Uma classe deve ser aberta para extensão, mas fechada para modificação. Em palavras simples, você poderá adicionar mais funcionalidades à classe, mas não editar as funções atuais de maneira a quebrar o código existente que a usa.
‌Liskov Substitution Principle: Esse princípio orienta o desenvolvedor a usar a herança de uma maneira que não interrompa a lógica do aplicativo em nenhum momento. Portanto, se uma classe filha chamada "XyClass" herdar de uma classe pai "AbClass", a classe filha não deve replicar uma funcionalidade da classe pai de uma maneira que altere o comportamento da classe pai. Portanto, você pode facilmente usar o objeto XyClass ao invés do objeto AbClass sem quebrar a lógica do aplicativo.
‌Interface Segregation Principle: Simplesmente, como uma classe pode implementar várias interfaces, estruture seu código de forma que uma classe nunca seja obrigada a implementar uma função que não é importante para o seu propósito. Portanto, categorize suas interfaces.
‌Dependency Inversion Principle: Se você seguiu o TDD para o desenvolvimento de seu aplicativo, então sabe como desacoplar seu código é importante para a testabilidade e a modularidade. Em outras palavras, se uma determinada classe "ex: Purchase" depende da classe "Users", a instanciação do objeto User deve vir de fora da classe "Purchase".

Padrões de design

‌Factory Pattern: É o padrão de design mais usado no mundo OOP porque economiza muito tempo no futuro quando você precisa modificar uma das classes que você usou.

Veja este exemplo:

Imagine que você deseja instanciar uma classe de modelo Users(), há duas maneiras de fazer isso:

$users = new Users();
$users = DataFactory::get("Users");

Eu preferiria o segundo caminho entre várias, por duas razões. Primeiro, alterar o nome da classe de "Users" para "UsersData" exigirá apenas uma alteração em um local "dentro do data factory" e o restante do seu código será o mesmo. Segundo, se a classe Users começar a usar parâmetros como ‌Users($connection); então você também precisará alterá-lo em um local e não em todas as funções que exigem o objeto Usuários. Então, se você acha que o primeiro caminho é melhor, pense novamente.

‌Adapter Pattern: O padrão do adaptador é um dos padrões de design estrutural. Pelo nome, você esperaria que ele convertesse o uso inesperado de classe em um esperado.

Imagine que seu aplicativo lida com a API do YouTube e, para obter o token de acesso, você precisa chamar uma função chamada getYoutubeToken();.

Então, você chamou essa função em 20 locais diferentes em seu aplicativo.

Em seguida, o Google lança uma nova versão da API do YouTube e a renomeou para getAccessToken();.

Agora você precisará localizar e substituir o nome da função em todos os lugares do aplicativo ou criar uma classe Adapter como no exemplo a seguir:

Nesse caso, você só precisa alterar uma linha e o restante do aplicativo continuará funcionando normalmente.

Como neste artigo não falamos sobre padrões de design em detalhes, aqui estão alguns links úteis, se você quiser saber mais:

Lembre-se de que existe uma diferença entre um arquiteto de software e um desenvolvedor de software. Os arquitetos de software geralmente têm líderes de equipe experientes, que têm um bom conhecimento sobre as soluções existentes que os ajudam a tomar decisões corretas na fase de planejamento. Um desenvolvedor de software deve saber mais sobre design de software e bastante sobre arquitetura de software para facilitar a comunicação interna dentro da equipe.