Ao formalizar a arquitetura do sistema, é importante entender não apenas o valor por trás do que a arquitetura trará para a mesa, mas também entender e apreciar o que deve ser.
Os principais objetivos do software ou da arquitetura técnica são identificar os requisitos não funcionais que são atendidos pelos atributos de qualidade que conduzirão a arquitetura do sistema .
Sobre requisitos não funcionais:
Um requisito não funcional é um requisito que especifica critérios que podem ser usados para julgar a operação de um sistema, em vez de comportamentos específicos. Eles são contrastados com os requisitos funcionais que definem comportamentos ou funções específicas. O plano para implementar requisitos funcionais é detalhado no design do sistema. O plano para implementar requisitos não funcionais é detalhado na arquitetura do sistema.
Em termos gerais, os requisitos funcionais definem o que um sistema deve fazer e os requisitos não funcionais definem como um sistema deve ser. ... Requisitos não funcionais são freqüentemente chamados de "atributos de qualidade" de um sistema. Outros termos para requisitos não funcionais são "qualidades", "objetivos de qualidade", "requisitos de qualidade de serviço", "restrições" e "requisitos não comportamentais"
É claro que identificar os requisitos significativos da arquitetura faz sentido quando em um projeto greenfield; no entanto, ao trabalhar com o software existente, é melhor ser o mais disciplinado possível. Você não deseja que sua arquitetura de software seja influenciada pelo sistema existente.
A arquitetura de software para ser autorizada realmente precisa ser de três coisas.
Declarativo
Esta é a parte da documentação em que você declara NÃO O QUE É, mas como as coisas deveriam ser. Fazemos isso através do uso de várias vistas arquitetônicas do sistema. Definimos os componentes que devem ser, como eles interagem e, opcionalmente, detalhamos cada componente para obter visualizações mais granulares que declaram como o sistema deve ser projetado.
Esta é uma distinção importante. O design do sistema deve ser restringido pela arquitetura do sistema, eles são de fato coisas separadas, mas relacionadas.
Fundamentação
A justificativa da sua arquitetura de software é o que fornece legitimidade e autoridade às decisões de arquitetura que foram tomadas. Talvez tenha sido tomada a decisão de utilizar um ouvinte de evento Pub / Sub no MQ para acionar um trabalho em lotes e você o diagrama?
Por que essa decisão foi tomada? Explicamos o porquê na seção Justificativa e vinculamos nossa explicação a Requisitos Não Funcionais, Metas de Atributos de Qualidade ou Requisitos Arquitetônicos Significativos. (Por exemplo, os trabalhos devem ser assíncronos e repetíveis, a Manutenção como um atributo de qualidade leva a que, no caso de uma falha no trabalho em lote, os trabalhos possam ser reiniciados por meio de uma mensagem do MQ. O sistema deve ter Zero Message Loss com comunicação assíncrona etc. ..)
Riscos
Agora que você declarou como a arquitetura deve ser e a provou com o seu Rationale, agora pode identificar Riscos no estado atual do sistema para onde isso não ocorre.
(Por exemplo, a validação do servidor está sendo duplicada no código Javascript do cliente. Isso é uma violação do princípio DRY e isso contraria o Atributo de Qualidade de Manutenção. Não há requisitos não-funcionais definidos em relação ao Desempenho nesta área. (não há justificativa para o comportamento atual do sistema)
Seus riscos também podem esquematizar onde o estado atual está atualmente divergindo da arquitetura. Esses riscos podem ser tratados pela equipe de desenvolvimento agora, através do plano do projeto ou adicionando-os ao backlog.