Arquitetura de Software: A diferença entre Arquitetura e Design
Tags: ptbr, webdev, architecture, beginners
Published: 2019-09-12 10:59:24

_Créditos Imagens [[Imagem 1](https://unsplash.com/photos/wVoMvN5NsU0), [Imagem 2](https://unsplash.com/photos/kP1AxmCyEXM)]_

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"](https://en.wikipedia.org/wiki/List_of_system_quality_attributes).

# 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](https://aws.amazon.com/serverless/).

# 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](https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven).

# 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.

![](https://miro.medium.com/1*4CPN7s890JsY9tEI4CRTDQ.png)

# 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: _**S**ingle Responsibility_, _**‌O**pen Closed_, _**‌L**iskov substitution_, _**‌I**nterface 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:

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

![](https://miro.medium.com/0*AEKNgJIc--U8znNj.png)

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();**.

![](https://miro.medium.com/0*TuX83nps-nqVeHfh.png)

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

![](https://miro.medium.com/0*RwcVkbTz5EAe8E8U.png)

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

![](https://miro.medium.com/0*qzGMIhXGLgnjlUNj.png)

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:

![](https://miro.medium.com/0*o_ID948yAZmqdJE8.png)

![](https://miro.medium.com/max/600/0*SwNrzpqoLEH6rf4c.png)

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

![](https://miro.medium.com/0*n-p9Qm2NBUVomLQi.png)

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

- https://code.tutsplus.com/series/design-patterns-in-php--cms-747 
- http://www.phptherightway.com/pages/Design-Patterns.html

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.

---

# Créditos

- [Software Architecture - The Difference Between Architecture and Design](https://codeburst.io/software-architecture-the-difference-between-architecture-and-design-7936abdd5830), escrito originalmente por [@maladdinsayed](https://codeburst.io/@maladdinsayed)