Você já ouviu o ditado, “arquitetos odeiam espaguete?” Como arquitetos de software, é nossa responsabilidade conceber e projetar sistemas capazes de suportar os modelos de negócios implacáveis desta era. Nesse sentido, é fundamental desenvolver maneiras de evoluir nossa arquitetura de aplicativo para combinar conceitos e processos de negócios corretamente. Do contrário, a arquitetura não será estruturalmente sólida e teremos que lidar com uma terrível “arquitetura espaguete”.

Nesta postagem do blog, compartilharei algumas das melhores práticas que você deve seguir para construir uma arquitetura de aplicativo estruturada e escalonável, evitando transformar seus sistemas em uma tigela de espaguete. Este artigo é baseado em um TechTalk recente sobre o mesmo tópico, Web and Mobile Architecture with Architecture Dashboard . 

Vamos começar?!

Por que a arquitetura de aplicativos é tão importante?

A arquitetura do aplicativo inclui todos os módulos e componentes do software, sistemas internos e externos e as interações entre eles que constituem um aplicativo. Uma arquitetura de aplicativo bem estruturada garante que seus aplicativos possam ser escalonados conforme as demandas de negócios, atendendo aos requisitos de negócios e usuários pretendidos, ao mesmo tempo em que garante que todos os conceitos sejam isolados corretamente e com dependências sólidas entre si.

Suponha que você ignore o lado da arquitetura dos aplicativos ao alterar e adicionar novos requisitos ao seu projeto de software. Você acabará ficando com uma arquitetura espaguete, um labirinto de sincronização e dependências não gerenciáveis entre diferentes partes do seu aplicativo.

                                                                                           Exemplo de uma arquitetura espaguete.

De baixo para cima:

• Camada de base: nesta camada, você implementa todos os requisitos não funcionais reutilizáveis, como serviços para se conectar a sistemas externos ou para estender sua estrutura usando bibliotecas de padrões de IU reutilizáveis e temas, por exemplo. Todos os tipos de requisitos não funcionais.
• Camada central: No topo da camada básica, você implementa seus serviços de negócios principais, incluindo serviços em torno de conceitos de negócios, regras de negócios, entidades de negócios, transações de negócios e widgets de negócios. Esses serviços devem ser agnósticos no sistema e baseados nos serviços básicos para abstrair qualquer detalhe de integração que você possa precisar. É nessas duas camadas inferiores que você isola todos os serviços ou componentes reutilizáveis.
• Camada do usuário final: a camada superior é onde você oferece suporte às interações dos usuários por meio de interfaces de usuário e processos, usando os serviços básicos e básicos para oferecer suporte à jornada do usuário. Observe que um módulo nesta camada nunca deve fornecer serviços a outros módulos para garantir a independência total do ciclo de vida. 

Validando a Estrutura de Sua Arquitetura

Para garantir que sua arquitetura seja sólida e que você não termine com uma arquitetura monolítica ou espaguete, você deve seguir um conjunto de diretrizes e recomendações. As regras a seguir referem-se a referências fortes entre módulos ou aplicativos (por exemplo, ações ou blocos), portanto, desconsidere referências soltas como Ações de serviço ou Destinos de tela.

1. Sem referências ascendentes nas 3 camadas:

Dada a camada estruturada, é evidente que não queremos que os serviços de base agnósticos de negócios dependam de conceitos de negócios centrais ou que qualquer serviço reutilizável dependa de interfaces de usuário final. Além disso, as referências ascendentes tendem a criar um cluster em que quaisquer dois módulos direta ou indiretamente vinculados têm uma dependência circular. Dê uma olhada no exemplo abaixo: 

O módulo B pode alcançar o módulo A indiretamente e o módulo A também pode alcançar o módulo B indiretamente. Portanto, temos um cluster de módulos interdependentes. E se você tiver outro módulo de usuário final (EU2) que está consumindo legitimamente o serviço principal B, ele se tornará dependente de todo o cluster. Consequentemente, não apenas seu tempo de execução recebe uma grande pegada desnecessária, mas também é afetado por alterações feitas em módulos dos quais ele nem deveria estar ciente.

2. Nenhuma referência lateral entre os usuários finais:

Os módulos de usuário final nunca devem fornecer serviços reutilizáveis para garantir que sejam isolados corretamente, permitindo que os usuários finais tenham diferentes ciclos de vida. Veja o exemplo abaixo:

Se o usuário final 1 consumir o usuário final 2, não só ele não pode ser independente de EU2, mas também não pode ser independente da hierarquia restante abaixo dele.

3. Evite referências circulares entre os módulos principais e fundamentais:

Se você seguir as duas regras anteriores, não precisará se preocupar com os ciclos entre os módulos do usuário final. Um ciclo é sempre indesejável, pois traz um impacto esperado sobre como gerenciar o código. Um ciclo entre os módulos indica que os conceitos não foram abstraídos corretamente.

No exemplo abaixo, uma das duas coisas deve acontecer:

 1) A e B estão tão fortemente conectados que devem fazer parte do mesmo módulo (por exemplo, Pedido e Linha de Pedido) ou….

 2) uma das dependências deve ser quebrada por colocar a lógica no lugar certo, de acordo com a relação esperada entre os conceitos. Por exemplo, os contratos dependem dos clientes, mas os clientes devem ser capazes de existir sem qualquer referência aos Contratos.

4. Recomendações extras:

• Os módulos principais não devem ter telas front-end: se você estiver implementando um serviço, talvez queira adicionar algumas telas para fazer testes de unidade. Mas, como desenvolvedor, depois de testar seu código, você deve se livrar das telas de teste. Se, por algum motivo, essas telas de teste forem úteis para suportar qualquer tipo de teste de regressão ou teste BDD , elas devem ser movidas para um módulo de teste do usuário final. Um dos principais perigos de manter telas de teste em seus módulos principais é que elas tendem a ser telas anônimas para fins de teste e, se terminarem em produção, abrem uma violação de segurança.

• Todas as entidades devem ser expostas como somente leitura: esta recomendação garante que você não está permitindo que os consumidores usem ações grosseiras para criar, atualizar ou excluir registros no banco de dados diretamente, porque o serviço principal deve abstrair as transações de negócios, cuidando de validações, normalizações e efeitos colaterais, como auditoria ou integração com outro sistema. Implemente todas as suas transações comerciais como ações públicas, para expor aos consumidores serviços seguros e corretamente abstratos.

• Evite a lógica de negócios na camada de base: às vezes, as pessoas tendem a implementar regras de negócios nesta camada, mas deve ser agnóstico de negócios para garantir que pode ser reutilizado em qualquer domínio de aplicativo.

• Não adicione entidades de negócios centrais na camada de base: novamente, para ser agnóstico de negócios, os módulos de base não devem ter entidades relacionadas aos negócios. Eles podem, no entanto, ter entidades não comerciais para oferecer suporte a alguns requisitos não funcionais de seus aplicativos. Por exemplo, se você precisa criar um serviço genérico para auditar todas as suas transações, pode criar uma entidade de auditoria. A auditoria em si não é assunto da sua empresa; o negócio da sua empresa é vender um produto ou provisionar um novo cliente ou alterar um contrato.

Composição do aplicativo usando a tela de arquitetura

Antes de passar pela composição da aplicação, uma rápida divulgação: neste contexto, “aplicação” não tem o mesmo significado que habitualmente lhe atribuímos em contexto empresarial.

Na OutSystems, usamos o termo “aplicativo” para se referir ao conjunto de módulos definidos no Service Studio – ambiente de desenvolvimento OutSystems – que constituem a unidade de implantação mínima para LifeTime – console OutSystems para gerenciar todos os seus ambientes, aplicativos, usuários de TI, segurança, e o ciclo de vida do aplicativo. Dito isto, o que se promove do Desenvolvimento à Qualidade e da Qualidade à Produção, não são módulos únicos, mas aplicações.

Para identificar a qual camada o aplicativo corresponde, você deve procurar a camada superior dos módulos dentro do aplicativo, o que significa que se a camada superior for um módulo de usuário final, por exemplo, então este é um aplicativo de usuário final.

Agora, com os aplicativos implementados, você deve seguir um conjunto de regras para garantir uma arquitetura correta.

Regra nº 1: Comece com as diretrizes da tela de arquitetura para módulos

Coloque seus módulos em camadas corretamente seguindo as diretrizes definidas acima.

Regra nº 2: Isole serviços comuns

Quando os módulos estão colocados corretamente no lugar, é hora de ir atrás dos aplicativos. Use os mesmos princípios aqui. Portanto, se você tiver um módulo em “aplicativo de usuário final 2” consumindo um módulo em “aplicativo de usuário final 1”, deve isolar o aplicativo de núcleo comum para evitar dependências. Dessa forma, você oferece suporte a ambos os aplicativos. No minuto em que você deseja compartilhar algo, é necessário isolar os serviços comuns em aplicativos comuns.

Regra nº 3: Não misture proprietários

Ter mais de um proprietário em um aplicativo resulta em um gerenciamento de implantação complexo, pois a responsabilidade pelo que foi alterado torna-se incerta. Promover a propriedade é fundamental. Se for impossível concentrar a propriedade de um aplicativo, considere dividi-lo de forma que a propriedade seja claramente definida.

Regra nº 4: Não misture patrocinadores

Assim como os proprietários, os patrocinadores têm demandas e bases diferentes. Vejamos um exemplo: imagine um portal que permite a simulação de diferentes ramos de negócios de seguros. Se todas as linhas de negócios estiverem sob a mesma aplicação, qualquer alteração feita em uma (por exemplo, no automóvel) não pode ser independente da outra. Portanto, a linha de negócios mais lenta ditará o ciclo de lançamento.

Ao criar aplicativos separados por linha de negócios, cada um pode determinar o ritmo de cada entrega. Uma vez que isso esteja claro, você deve identificar e isolar tudo o que é compartilhado entre os diferentes patrocinadores e o que deve ser administrado em conjunto.

Quer ver o Architecture Canvas em ação?

Então, eu convido você a se juntar a mim em meu recente Tech Talk Web e Mobile Architecture with Architecture Dashboard . Nesta sessão, mostrarei como projetar uma arquitetura seguindo o princípio da tela e algumas das melhores práticas que você deve ter em mente para evitar a arquitetura espaguete, usando um exemplo da vida real. Também examinarei o Architecture Dashboard , uma ferramenta para ajudá-lo a avaliar o que você fez.

Espero ver você lá!