Princípios chave

A arquitetura de software é descrita como a organização de um sistema, onde o sistema representa um conjunto de componentes que cumprem as funções definidas.

Estilo arquitetônico

o architectural style, também chamado de architectural pattern, é um conjunto de princípios que moldam um aplicativo. Ele define uma estrutura abstrata para uma família de sistema em termos do padrão de organização estrutural.

O estilo arquitetônico é responsável por -

Fornece um léxico de componentes e conectores com regras sobre como eles podem ser combinados.
Melhore o particionamento e permita a reutilização do design, fornecendo soluções para problemas que ocorrem com frequência.
Descreva uma maneira particular de configurar uma coleção de componentes (um módulo com interfaces bem definidas, reutilizáveis e substituíveis) e conectores (link de comunicação entre módulos).

O software desenvolvido para sistemas baseados em computador exibe um dos muitos estilos arquitetônicos. Cada estilo descreve uma categoria de sistema que abrange -

Um conjunto de tipos de componentes que executam uma função exigida pelo sistema.
Um conjunto de conectores (chamada de sub-rotina, chamada de procedimento remoto, fluxo de dados e soquete) que permite a comunicação, coordenação e cooperação entre diferentes componentes.
Restrições semânticas que definem como os componentes podem ser integrados para formar o sistema.
Um layout topológico dos componentes indicando seus inter-relacionamentos em tempo de execução.

Projeto Arquitetônico Comum

A tabela a seguir lista os estilos arquitetônicos que podem ser organizados por sua área de foco principal -

Categoria	Projeto arquitetônico	Descrição
Comunicação	Bus de mensagens	Prescreve o uso de um sistema de software que pode receber e enviar mensagens usando um ou mais canais de comunicação.
Comunicação	Arquitetura Orientada a Serviços (SOA)	Define os aplicativos que expõem e consomem funcionalidade como um serviço usando contratos e mensagens.
Desdobramento, desenvolvimento	Servidor cliente	Separe o sistema em dois aplicativos, onde o cliente faz solicitações ao servidor.
Desdobramento, desenvolvimento	3-tier ou N-tier	Separa a funcionalidade em segmentos separados com cada segmento sendo uma camada localizada em um computador fisicamente separado.
Domínio	Design Orientado por Domínio	Focado na modelagem de um domínio de negócios e definição de objetos de negócios com base em entidades dentro do domínio de negócios.
Estrutura	Com base em componente	Divida o design do aplicativo em componentes funcionais ou lógicos reutilizáveis que expõem interfaces de comunicação bem definidas.
	Em camadas	Divida as preocupações do aplicativo em grupos empilhados (camadas).
	Orientado a Objeto	Com base na divisão de responsabilidades de um aplicativo ou sistema em objetos, cada um contendo os dados e o comportamento relevante para o objeto.

Tipos de Arquitetura

Existem quatro tipos de arquitetura do ponto de vista de uma empresa e, coletivamente, essas arquiteturas são referidas como enterprise architecture.

Business architecture - Define a estratégia de negócios, governança, organização e processos-chave de negócios dentro de uma empresa e se concentra na análise e design de processos de negócios.
Application (software) architecture - Serve como modelo para sistemas de aplicativos individuais, suas interações e seus relacionamentos com os processos de negócios da organização.
Information architecture - Define os ativos de dados lógicos e físicos e os recursos de gerenciamento de dados.
Information technology (IT) architecture - Define os blocos de construção de hardware e software que compõem o sistema de informações geral da organização.

Processo de Design de Arquitetura

O processo de design de arquitetura concentra-se na decomposição de um sistema em diferentes componentes e suas interações para satisfazer os requisitos funcionais e não funcionais. As principais entradas para o design de arquitetura de software são -

Os requisitos produzidos pelas tarefas de análise.
A arquitetura de hardware (o arquiteto de software, por sua vez, fornece requisitos para o arquiteto de sistema, que configura a arquitetura de hardware).

O resultado ou saída do processo de design de arquitetura é um architectural description. O processo básico de design de arquitetura é composto das seguintes etapas -

Entenda o problema

Esta é a etapa mais importante porque afeta a qualidade do design que se segue.
Sem uma compreensão clara do problema, não é possível criar uma solução eficaz.
Muitos projetos e produtos de software são considerados falhas porque não resolveram realmente um problema de negócios válido ou tiveram um retorno sobre o investimento (ROI) reconhecível.

Identifique os elementos de design e seus relacionamentos

Nesta fase, construa uma linha de base para definir os limites e o contexto do sistema.
Decomposição do sistema em seus componentes principais com base nos requisitos funcionais. A decomposição pode ser modelada usando uma matriz de estrutura de design (DSM), que mostra as dependências entre os elementos de design sem especificar a granularidade dos elementos.
Nesta etapa, a primeira validação da arquitetura é feita descrevendo um número de instâncias do sistema e esta etapa é referida como design de arquitetura baseado em funcionalidade.

Avalie o projeto de arquitetura

Cada atributo de qualidade recebe uma estimativa, portanto, para reunir medidas qualitativas ou dados quantitativos, o projeto é avaliado.
Envolve a avaliação da arquitetura quanto à conformidade com os requisitos de atributos de qualidade da arquitetura.
Se todos os atributos de qualidade estimados estiverem de acordo com o padrão exigido, o processo de projeto arquitetônico estará concluído.
Caso contrário, a terceira fase do projeto de arquitetura de software é inserida: transformação da arquitetura. Se o atributo de qualidade observado não atender aos seus requisitos, um novo design deve ser criado.

Transforme o projeto de arquitetura

Esta etapa é realizada após uma avaliação do projeto arquitetônico. O projeto arquitetônico deve ser alterado até que satisfaça completamente os requisitos de atributo de qualidade.
Ele se preocupa em selecionar soluções de design para melhorar os atributos de qualidade, preservando a funcionalidade do domínio.
Um design é transformado pela aplicação de operadores, estilos ou padrões de design. Para transformação, pegue o design existente e aplique o operador de design, como decomposição, replicação, compactação, abstração e compartilhamento de recursos.
O projeto é avaliado novamente e o mesmo processo é repetido várias vezes se necessário e até mesmo executado recursivamente.
As transformações (isto é, soluções de otimização de atributos de qualidade) geralmente melhoram um ou alguns atributos de qualidade enquanto afetam outros negativamente

Princípios Chave de Arquitetura

A seguir estão os princípios-chave a serem considerados ao projetar uma arquitetura -

Construir para mudar em vez de construir para durar

Considere como o aplicativo pode precisar ser alterado ao longo do tempo para lidar com novos requisitos e desafios e construir a flexibilidade para oferecer suporte a isso.

Reduza o risco e modelo para analisar

Use ferramentas de design, visualizações, sistemas de modelagem como UML para capturar requisitos e decisões de design. Os impactos também podem ser analisados. Não formalize o modelo a ponto de suprimir a capacidade de iterar e adaptar o design facilmente.

Use modelos e visualizações como uma ferramenta de comunicação e colaboração

A comunicação eficiente do design, das decisões e das mudanças contínuas no design é crítica para uma boa arquitetura. Use modelos, visualizações e outras visualizações da arquitetura para comunicar e compartilhar o design de forma eficiente com todas as partes interessadas. Isso permite a comunicação rápida de alterações no design.

Identifique e compreenda as principais decisões de engenharia e áreas onde os erros são cometidos com mais frequência. Invista em tomar decisões importantes da primeira vez para tornar o design mais flexível e com menos probabilidade de ser interrompido por alterações.

Use uma abordagem incremental e iterativa

Comece com a arquitetura de linha de base e, em seguida, desenvolva as arquiteturas candidatas por meio de testes iterativos para melhorar a arquitetura. Adicione iterativamente detalhes ao design em vários passes para obter a imagem grande ou certa e, em seguida, concentre-se nos detalhes.

Princípios Chave de Design

A seguir estão os princípios de design a serem considerados para minimizar custos, requisitos de manutenção e maximizar extensibilidade e usabilidade da arquitetura -

Separação de preocupações

Divida os componentes do sistema em recursos específicos para que não haja sobreposição entre as funcionalidades dos componentes. Isso fornecerá alta coesão e baixo acoplamento. Esta abordagem evita a interdependência entre os componentes do sistema, o que ajuda na manutenção do sistema fácil.

Princípio de Responsabilidade Única

Cada módulo de um sistema deve ter uma responsabilidade específica, o que ajuda o usuário a compreender claramente o sistema. Também deve ajudar na integração do componente com outros componentes.

Princípio do mínimo conhecimento

Qualquer componente ou objeto não deve ter conhecimento sobre os detalhes internos de outros componentes. Essa abordagem evita a interdependência e ajuda na manutenção.

Minimize grande design inicial

Minimize o design grande antecipadamente se os requisitos de um aplicativo não forem claros. Se houver a possibilidade de modificar os requisitos, evite fazer um design grande para todo o sistema.

Não repita a funcionalidade

Não repetir a funcionalidade especifica que a funcionalidade dos componentes não deve ser repetida e, portanto, uma parte do código deve ser implementada em apenas um componente. A duplicação da funcionalidade em um aplicativo pode dificultar a implementação de alterações, diminuir a clareza e introduzir possíveis inconsistências.

Prefira composição em vez de herança ao reutilizar a funcionalidade

A herança cria dependência entre as classes filhas e pais e, portanto, bloqueia o uso gratuito das classes filhas. Em contraste, a composição fornece um grande nível de liberdade e reduz as hierarquias de herança.

Identificar componentes e agrupá-los em camadas lógicas

Componentes de identidade e a área de preocupação que são necessários no sistema para satisfazer os requisitos. Em seguida, agrupe esses componentes relacionados em uma camada lógica, o que ajudará o usuário a entender a estrutura do sistema em um alto nível. Evite misturar componentes de diferentes tipos de interesses na mesma camada.

Defina o protocolo de comunicação entre as camadas

Entenda como os componentes se comunicarão entre si, o que requer um conhecimento completo dos cenários de implantação e do ambiente de produção.

Definir formato de dados para uma camada

Vários componentes irão interagir uns com os outros por meio do formato de dados. Não misture os formatos de dados para que os aplicativos sejam fáceis de implementar, estender e manter. Tente manter o mesmo formato de dados para uma camada, de modo que vários componentes não precisem codificar / decodificar os dados enquanto se comunicam entre si. Ele reduz a sobrecarga de processamento.

Os componentes do serviço do sistema devem ser abstratos

O código relacionado à segurança, comunicações ou serviços do sistema, como registro, criação de perfil e configuração, deve ser abstraído em componentes separados. Não misture esse código com a lógica de negócios, pois é fácil estender o design e mantê-lo.

Projetar exceções e mecanismo de tratamento de exceções

Definir exceções com antecedência, ajuda os componentes a gerenciar erros ou situações indesejadas de maneira elegante. O gerenciamento de exceções será o mesmo em todo o sistema.

Convenções de Nomenclatura

As convenções de nomenclatura devem ser definidas com antecedência. Eles fornecem um modelo consistente que ajuda os usuários a entender o sistema facilmente. É mais fácil para os membros da equipe validar o código escrito por outros e, portanto, aumentará a capacidade de manutenção.