Analisando arquiteturas client-side com AngularJS

O desenvolvimento de uma arquitetura client-side, traz consigo desafios arquiteturais equivalentes ao modelo tradicional implementado no lado servidor. Então como podemos modelar e implementar uma arquitetura no lado cliente capaz de atender aos requisitos arquiteturais de software de um determinado domínio?

Para o propósito deste artigo, foi selecionado o domínio de uma rede social para realizar a implementação baseada nos requisitos da arquitetura que serão descritos empregando o modelo FURPS, um acrônimo que representa um modelo de classificação de atributos de qualidade de software (requisitos funcionais e não funcionais), e que classifica os requisitos arquiteturais por funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade.

Neste contexto, a escolha do framework AngularJS foi realizada devido a sua popularidade e ao fato de suas características serem compatíveis com uma arquitetura robusta que possibilita a separação em camadas, assim como outras características importantes como a injeção de dependências.

Arquitetura de Software

Segundo Martin Fowler, a arquitetura de software é um termo com muitas definições, porém sem um consenso entre os autores. No entanto, ele afirma que sempre existem dois elementos em comum, o primeiro é o desmembramento do sistema em partes e o segundo são as decisões difíceis de mudar.

A arquitetura de software de um programa ou sistema computacional é composta pelas estruturas do sistema, que, por sua vez, são compostas por elementos de software, suas propriedades visíveis externamente e as relações entre elas. As formas arquiteturais recorrentes, depois de observadas e analisadas, podem gerar modelos padronizados, que podem ser utilizados mesmo em sistemas diferentes na forma dos chamados “estilos arquiteturais”, modelos de representação de arquitetura.

O estilo arquitetural mais utilizado em aplicações complexas é o estilo em camadas, também conhecido como layers, no qual ele define como um conjunto de subsistemas do software organizados em forma de bolo, onde cada camada é acomodada sobre a camada inferior.

Nesta estrutura a maior camada utiliza os serviços das camadas inferiores, mas as camadas inferiores não conhecem as camadas superiores e por isso não acessam os seus serviços. Entre os benefícios disso, podemos citar: coesão; separação de responsabilidades; redução de dependências; possibilidade de substituição da implementação.

Padrões de Projeto

O software é frequentemente lembrado pelas suas partes como as funções, arquivos fonte, módulos, objetos, métodos, classes, pacotes, bibliotecas, componentes, serviços, subsistemas e assim por diante.

Tudo isto representa visões corretas nas quais os desenvolvedores trabalham. Porém esta visão é focada nas partes, que por sua vez não contemplam a grande quantidade de relacionamentos e decisões que estão por trás do software.

Os padrões de projeto, também conhecidos como design patterns, surgem para descrever, capturar e nomear técnicas para solução de problemas de software. Diferentemente da utilização de experiência de forma empírica, os padrões são documentados, reutilizados em outras aplicações e compartilhados para disseminação do conhecimento.

Os principais padrões de projetos que serão empregados neste artigo estão descritos a seguir.

Dependency Injection

O padrão DI (Dependency Injection) é uma prática onde os objetos são desenhados de uma maneira na qual recebem instâncias de objetos de outras partes do código, ao invés de construí-los internamente.

Isto significa que qualquer implementação da interface que é utilizada pelo objeto pode ser substituída sem alterar o código, resultando na simplificação dos testes e na diminuição do acoplamento.

Service Oriented Architecture

O padrão SOA (Service Oriented Architecture) consiste em uma coleção de componentes distribuídos que fornecem e/ou consomem serviços. Neste padrão, os componentes dos fornecedores e dos consumidores de serviços podem utilizar diferentes plataformas e linguagens de programação.

Serviços são em sua grande maioria independentes e frequentemente pertencem a diferentes sistemas ou até mesmo diferentes organizações.

RESTful Web Services

O REST (Representational State Transfer) é um estilo arquitetural para aplicações em rede proposto por Roy Fielding em 2000. Ele consiste em um conjunto de restrições para tratar a separação de responsabilidades, visibilidade, confiabilidade, escalabilidade, desempenho, etc.

O grande diferencial do REST é a utilização da infraestrutura da web, como por exemplo, o protocolo HTTP, que permite construir aplicações distribuídas e publicar serviços nesta infraestrutura.

Pode ser denominado RESTful Web Services, os serviços web construídos utilizando as tecnologias HTTP, URI, XML e JSON que são padronizadas para utilização na web.

Active Record

O Active Record é um padrão arquitetural para mapeamento de objetos de domínio a estruturas de dados, representando uma tabela ou um documento e encapsulando o acesso ao repositório de dados. Ele é recomendado para domínios com pouca lógica de negócio e que se aproximam muito da modelagem dos dados.

Requisitos Arquiteturais

Para analisar os requisitos arquiteturais, primeiramente precisamos compreender como identificá-los e classificá-los.

Um requisito de software pode ser chamado de r ...