.NET - Arquitetura de um projeto de software

 Neste artigo veremos uma introdução aos conceitos de arquitetura de um projeto de software usados na plataforma .NET.  

Vamos iniciar definindo o que é arquitetura de um projeto de software ou seja arquitetura de uma aplicação.

Existem muitas definições de arquitetura de software :

“Uma arquitetura de software envolve a descrição de elementos arquiteturais dos quais os sistemas serão construídos, interações entre esses elementos, padrões que guiam suas composições e restrições sobre estes padrões”.GARLAN, 2000

"A arquitetura de software define o que é o sistema em termos de componentes computacionais e os relacionamentos entre estes componentes." VAROTO, 2002

"A arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do sistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entre projetos." http://pt.wikipedia.org/wiki/Arquitetura_de_software, acessado em 2012

Na verdade essa tarefa não é tão simples como parece realmente  não é fácil encontrar uma definição exata para arquitetura de um aplicativo.

Pode-se argumentar que é um subconjunto da arquitetura de software que se concentra principalmente em aplicativos individuais em contraste com, por exemplo, a arquitetura corporativa, que abrange todo o software dentro de uma empresa, incluindo as interações entre diferentes aplicativos.

Podemos dizer então que a arquitetura do aplicativo é responsável pela estrutura de alto nível de um aplicativo que serve como uma diretriz ou um projeto para todo o trabalho de desenvolvimento nesse aplicativo.

Freqüentemente, as pessoas comparam isso à arquitetura de construção. No entanto, existe uma diferença muito importante entre os dois.

Ao contrário dos edifícios, o software muda muito e nunca está realmente "pronto". Isso se reflete em sua arquitetura, que também precisa se adaptar constantemente às mudanças de requisitos e ao desenvolvimento.

Assim, a arquitetura de um aplicativo deve sempre ser baseada nos requisitos conforme especificado pelas partes interessadas (proprietários de negócios, usuários, etc.).

É importante que isso não inclua apenas os requisitos funcionais (ou seja, o que o aplicativo precisa fazer), mas também os não funcionais. Este último está preocupado com o desempenho do aplicativo, confiabilidade, capacidade de manutenção e outros aspectos que não afetam diretamente sua funcionalidade, mas têm um impacto em como o aplicativo é experimentado por seus usuários, desenvolvedores e outras partes interessadas.

Aspectos da arquitetura de uma aplicação

As decisões com relação a arquitetura são feitas em diferentes níveis de um projeto:

 

Normalmente, a arquitetura do aplicativo começa com a escolha do tipo de aplicativo a ser desenvolvido.

Será um aplicativo web ou será executado localmente em um dispositivo (móvel ou desktop)?

A escolha dependerá de vários fatores:

- O aplicativo será usado em um computador, em um telefone celular ou em ambos ?
- Os usuários sempre terão conectividade com a Internet ou também a usarão no modo off-line ?
- O aplicativo aproveita ou mesmo exige a utilização de serviços e sensores disponíveis nos aparelhos, como notificações, geolocalização, câmera fotográfica, etc.

A tecnologia usada esta relacionada com o tipo de aplicativo e mesmo que você já tenha decidido sobre a pilha de tecnologia .NET, ainda há muitas opções para todos os tipos de aplicativos: desktop, celular e web.

Depois de decidir sobre o tipo de aplicativo e a pilha de tecnologia, é hora de examinar os padrões de arquitetura.

Padrões de Arquitetura

Os padrões de arquitetura têm uma função semelhante aos padrões de projeto, apenas que são aplicáveis ​​em um nível superior. Eles são soluções reutilizáveis ​​comprovadas para cenários comuns na arquitetura de software.

Vejamos a seguir os principais padrões de arquitetura :

1- Arquitetura em Camadas

Na arquitetura multicamadas, os aplicativos são estruturados em várias camadas que têm responsabilidades separadas e, geralmente, também são fisicamente separadas.

Provavelmente, a aplicação mais comum deste padrão arquitetônico é a arquitetura em três camadas que consiste em uma camada de acesso a dados (incluindo armazenamento de dados), uma camada de negócios (implementando a lógica de negócios) e uma camada de apresentação (ou seja, a interface de usuário do aplicativo).

2- Arquitetura Orientada a Serviços

Na arquitetura orientada a serviços (SOA), os componentes do aplicativo são implementados como serviços autônomos independentes que se comunicam por meio de um protocolo de comunicação padronizado.

Um contrato de serviço padronizado descreve a funcionalidade exposta por cada serviço. Isso permite um acoplamento fraco entre os serviços e alto nível de reutilização. Quando o padrão de arquitetura foi introduzido pela primeira vez, o protocolo de comunicação mais comumente usado era o SOAP.

3- Microsserviços

Os microsserviços são um subconjunto mais moderno ou uma evolução da arquitetura orientada a serviços (SOA). Como o nome indica, eles geralmente são mais leves, incluindo os protocolos de comunicação que geralmente são REST e gRPC.

Cada serviço pode usar qualquer tecnologia que funcione melhor para ele, mas todos devem ser implementados de forma independente com um alto nível de automação.

Os Microsserviços prometem uma maneira melhor de gerar um impacto nos negócios de forma sustentável. Em vez de uma única unidade monolítica, as aplicações construídas usando microsserviços são compostas de serviços fracamente acoplados e autônomos.

A figura abaixo mostra uma típica arquitetura em camadas de uma aplicação monolítica:

Ao construir serviços que fazem bem uma coisa, você pode evitar a inércia e a entropia de grandes aplicações. Mesmo em aplicativos existentes, você pode progressivamente extrair funcionalidades em serviços independentes para tornar todo o seu sistema mais sustentável.

Quando começamos a trabalhar com microsserviços, percebemos rapidamente que construir serviços pequenos e auto-suficientes é apenas uma parte da execução de uma aplicação de negócio critica.

Abaixo temos uma figura que mostra como podemos dividir uma aplicação em microsserviços:


 4- Arquitetura orientada a Eventos

Na arquitetura orientada a eventos, há ainda mais ênfase no acoplamento fraco e na comunicação assíncrona entre os componentes. Embora não seja um requisito, o sistema ainda pode ser distribuído, ou seja, pode consistir em serviços independentes (ou microsserviços).

O principal fator de distinção é que os componentes não se comunicam com chamadas imperativas. Em vez disso, toda a comunicação ocorre por meio de eventos (ou mensagens) que são postados por componentes e, em seguida, ouvidos por outros componentes que têm interesse neles.

O componente que publica o evento não recebe nenhuma resposta direta a ele. No entanto, ele pode receber uma resposta indireta ao ouvir uma mensagem diferente. Isso torna a comunicação mais assíncrona quando comparada com os outros padrões.

Decisões dentro de uma arquitetura

Dentro de um padrão de arquitetura de alto nível selecionado, ainda existem muitas decisões de arquitetura de nível inferior a serem feitas que especificam como um código de aplicativo será estruturado, com ainda mais detalhes.

Existem outros padrões disponíveis para essas decisões, como o padrão Model-View-Controller (MVC) para aplicativos da web e o padrão Model-View-Viewmodel (MVVM) para aplicativos de desktop.

À medida que o escopo desses padrões se torna ainda menor, às vezes os chamamos de padrões de projeto em vez de padrões arquitetônicos. Exemplos desses padrões são injeção de dependência, Singleton, Factory, e outros.

Após a definição da arquitetura inicial do aplicativo, é necessário avaliar como ela atende à lista de requisitos em que se baseia. Isso é importante porque, na maioria dos casos, não há uma única escolha correta para os requisitos fornecidos.

Sempre há compromissos e cada escolha tem seu próprio conjunto de vantagens e desvantagens.

Uma certa escolha de arquitetura pode, por exemplo, melhorar o desempenho do aplicativo, mas também aumentar os custos operacionais e reduzir a capacidade de manutenção. Dependendo da importância relativa dos requisitos afetados, essa escolha de arquitetura pode fazer sentido ou não.

A arquitetura de um projeto não é imutável

A arquitetura do aplicativo nunca é imutável.

Ela precisa evoluir conforme o aplicativo está sendo desenvolvido e novos conhecimentos e experiências são reunidos. Se um determinado padrão não funcionar conforme o esperado nas circunstâncias dadas, ele deve ser reavaliado e considerado para uma mudança.

Os requisitos (funcionais e não funcionais) podem mudar e afetar decisões arquitetônicas anteriores também. Claro, alguns padrões arquitetônicos são mais fáceis de mudar do que outros.

Por exemplo, é muito mais fácil introduzir injeção de dependência em um aplicativo ou alterar sua implementação do que alterar o tipo de aplicativo ou padrão arquitetônico central, como MVC.

Arquitetura de projeto na plataforma .NET

Se você está se concentrando na pilha de tecnologia da plataforma .NET e Azure, a Microsoft oferece muitos recursos oficiais para ajudá-lo a começar a arquitetar aplicativos.

O site .NET Architecture Guides é o melhor ponto de partida. Os recursos do site são organizados com base no tipo de aplicativo que você deseja desenvolver. Depois de selecionar um (por exemplo, aplicativos ASP.NET ou aplicativos de desktop UWP), você obtém uma lista de e-books gratuitos para baixar que são aplicáveis ao tipo de aplicativo selecionado.

O mesmo e-book pode ser listado em vários tipos de aplicativos se a orientação que ele contém se aplica a mais de um.

Em geral, os e-books seguem uma abordagem semelhante e fazem um bom trabalho ao apresentar ao leitor o tópico que cobrem.

Normalmente, eles incluem o seguinte:

- Uma introdução às tecnologias envolvidas.
- Uma visão geral dos subtipos de aplicativos disponíveis (por exemplo, MVC vs. aplicativos da web de página única) e o raciocínio por trás da escolha de um.
- Uma lista de padrões de arquitetura comuns para o tipo de aplicativo com explicação.
- Um tutorial que cobre as principais partes de um aplicativo, incluindo código de amostra.

Os livros visam principalmente leitores sem experiência anterior no assunto que cobrem. Seu conteúdo é adequado para arquitetos e desenvolvedores de software. Eles ainda podem ser uma leitura valiosa, mesmo se você tiver algum conhecimento prévio.

Nesse caso, você pode pular algumas partes do livro ou folheá-las, mas mesmo assim você pode pegar algumas coisas ou obter uma visão geral mais completa do tópico.

Com isso você têm disponível um material de qualidade e gratuito para te ajudar no seu desenvolvimento pessoal.

E estamos conversados...

"Cheguemos, pois, com confiança ao trono da graça, para que possamos alcançar misericórdia e achar graça, a fim de sermos ajudados em tempo oportuno."
Hebreus 4:16

Referências:

José Carlos Macoratti