Arquitetura de Projeto em OutSystems

Arquitetura Canvas 

O Architecture Canvas é uma ferramenta de arquitetura da OutSystems para simplificar o design de Arquiteturas Orientadas a Serviços (SOA). Promove a correta abstração de (micro)serviços reutilizáveis ​​e o correto isolamento de módulos funcionais distintos, nos casos em que se está desenvolvendo e mantendo múltiplas aplicações que reutilizam módulos comuns. Uma instalação típica de OutSystems de médio a grande porte suportará mais de 20 aplicativos de missão crítica e mais de 200 módulos interdependentes. 

Esses aplicativos/módulos têm ciclos de vida de mudança diferentes e são mantidos e patrocinados por equipes diferentes. Novos aplicativos tendem a evoluir rapidamente, enquanto serviços altamente reutilizados mudarão muito mais lentamente. O benefício mais importante que você obtém de uma arquitetura bem projetada é que os aplicativos e os módulos que os compõem preservarão ciclos de vida independentes e reduzirão ao mínimo as dependências e o impacto geral da mudança. O resultado é um design de arquitetura OutSystems econômico, mais fácil de manter e evoluir. 

As camadas e subcamadas 

Cada camada e subcamada define uma natureza diferente da funcionalidade a ser capturada em um módulo: 

As subcamadas são mostradas em detalhes abaixo: 

Projeto de arquitetura com o Architecture Canvas 

O Architecture Canvas é usado em dois estágios diferentes do projeto de arquitetura: 

1. Identificando conceitos (necessidades funcionais, não funcionais e de integração) O canvas auxilia na coleta de requisitos de arquitetura de forma estruturada e sistemática.  

1. Definir os módulos Projetar os módulos que implementam os conceitos identificados, seguindo os padrões recomendados. 

Projetar uma arquitetura não é um evento único. É um processo contínuo. A arquitetura deve ser iterada, percorrendo esses dois estágios, à medida que uma solução evolui e novos conceitos e necessidades surgem de seus negócios. 

Aplicando o Architecture Canvas a Aplicativos 

Para analisar a arquitetura do aplicativo, os princípios do Architecture Canvas desempenham um papel importante, assim como na arquitetura do módulo. 

Da mesma forma que os módulos individuais são classificados em um Architecture Canvas, cada aplicativo também é colocado em uma das camadas. 

Os aplicativos devem ser colocados na mesma camada que a camada de módulo superior. A representação a seguir mostra a natureza dos módulos que compõem cada aplicação, bem como a aplicação adotando a natureza de seu módulo superior. 

As candidaturas estão sujeitas às mesmas regras de validação, respeitando as relações entre si: 

1. Sem referências ascendentes 
2. Sem referências secundárias entre aplicativos de usuário final ou aplicativos de orquestração 
3. Nenhuma referência cíclica entre dois aplicativos 

A mesma lógica se aplica a módulos e aplicativos. Os aplicativos de orquestração e de usuário final não devem fornecer serviços reutilizáveis ​​para garantir a independência de seu ciclo de vida. Por exemplo, um aplicativo de usuário final pode conter módulos de núcleo e biblioteca reutilizáveis, desde que sejam consumidos apenas por outros módulos do mesmo aplicativo. 

Validando a arquitetura do seu aplicativo 

Existem 3 regras que você deve sempre cumprir para obter uma arquitetura de aplicativo bem projetada. 

A conformidade dos módulos implementados com essas regras de arquitetura pode ser verificada automaticamente por meio da ferramenta Discovery. Ele analisa as dependências reais entre os módulos, identificando violações e apontando os elementos (ações, telas, entidades) que estão montados no lugar errado. 

Regra nº1 - Sem referências ascendentes 

Uma referência ascendente tende a criar um cluster onde quaisquer 2 módulos, direta ou indiretamente, têm uma dependência circular. 

Neste exemplo, como a Biblioteca E consome o usuário final A , qualquer par de elementos dentro do cluster identificado está em uma relação circular. Pegue C e D, por exemplo: C > E > A > D e inverta D > E > A > C. 

Outro efeito inesperado é que o usuário final B está consumindo legitimamente o Core D e se torna dependente de todo o cluster. Não apenas seu tempo de execução terá uma pegada desnecessariamente grande, mas também será constantemente impactado (desatualizado) com alterações feitas em módulos das quais ele nem deveria estar ciente. 

O que está errado? 

Uma violação ascendente identifica claramente que os serviços não estão devidamente isolados. 

Como corrigi-lo? 

Encontre os elementos que estão sendo consumidos e mova-os para uma camada inferior. Nesse caso, mova o serviço reutilizável em A para uma Biblioteca, eventualmente para o próprio E, se ele se enquadrar no mesmo conceito. 

Regra nº2 - Sem referências secundárias entre usuários finais ou orquestrações 

Neste exemplo, o usuário final A está consumindo algum elemento do usuário final B (talvez algo tão simples quanto uma função de formatação). Não só foi acoplado ao módulo B, como também herdou D, E e G desnecessariamente. 

O que está errado? 

Os módulos de usuário final ou orquestração não devem fornecer serviços reutilizáveis. Isso garante que eles estejam corretamente isolados, permitindo que tenham diferentes ciclos de vida - diferentes ritmos de versão devido a diferentes patrocinadores ou equipes de projeto. 

Esse isolamento é crítico, pois os usuários finais e as orquestrações estão no topo da hierarquia. Uma referência a tais módulos tende a trazer um enorme conjunto de dependências indiretas de camadas inferiores. 

Como corrigi-lo? 

Descubra quais são os elementos de B sendo consumidos por A e mova-os para um novo (ou existente, se houver um ajuste conceitual) módulo de camada inferior: 

• Para um módulo Core se for relacionado a negócios. 
• Para uma Biblioteca se for independente de negócios. 

Regra nº3 - Sem ciclos entre Núcleos ou Bibliotecas 

Respeitando as regras nº1 e nº2, os usuários finais e orquestrações não podem estar envolvidos em nenhuma referência cíclica. 

A terceira regra é sobre evitar ciclos entre Cores ou Libraries, já que esses podem ter referências laterais. 

Um ciclo é sempre indesejável, pois traz impactos inesperados e códigos difíceis de gerenciar. 

O que está errado? 

Um ciclo entre os módulos indica que os conceitos não estão corretamente abstraídos. 

Um ciclo entre A e B indica que: 

• Eles são fortemente acoplados, ou; 
• Uma das direções é indesejável. Por exemplo, A deveria estar conceitualmente consumindo B porque o conceito em A estende B. 

Como corrigi-lo? 

Na maioria das vezes, se houver claramente uma direção indesejável na relação, os conceitos devem ser movidos para outro módulo. 

Por exemplo, se é B que não deve consumir A, então os elementos de A consumidos por B devem ser: 

• Movidos para um novo módulo, caso representem outro conceito reutilizável, ou; 
• Movidos para o próprio B, se fossem elementos extraviados do mesmo conceito. 

No entanto, se A e B estiverem fortemente acoplados, eles devem ser mesclados. 

Se essa mesclagem resultar em um módulo muito grande, pode ser necessário criar um terceiro módulo acima dos dois. Os dois módulos originais representam conceitos básicos e o novo módulo normalmente fornece regras de negócios, para dar suporte a algum processo do usuário final, que precisa lidar com ambos os conceitos básicos. Essa lógica de composição é a causadora do ciclo.