Como desenhar arquitetura de software: dicas e práticas recomendadas

Você não gostaria de entrar em um projeto sem um plano sólido. E para o desenho da arquitetura de software, a situação não seria diferente. Ao tornar esse processo mais eficaz, você pode levar em conta todos os seus requisitos adequadamente e dar às partes envolvidas a oportunidade de oferecer suas contribuições.

Usando recursos visuais técnicos e um processo de planejamento cuidadoso, você pode delinear a arquitetura e o desenho do seu software antes de começar um protótipo. 

O que é desenho de arquitetura de software? 

O desenho de arquitetura de software usa conhecimento de programação para planejar o desenho de alto nível do software para que os detalhes possam ser adicionados posteriormente, permitindo que as equipes de software esbocem o quadro geral e comecem a preparar um protótipo. 

Ao seguir as dicas de desenho de arquitetura de software e as práticas recomendadas, os desenvolvedores de software podem refletir sobre as características de seus softwares e determinar como projetar a arquitetura de software. 

Como desenhar arquitetura de software em 5 etapas

1. Tenha um entendimento claro de seus requisitos

Cada desenho em que você embarcar terá requisitos funcionais e não funcionais. Esses requisitos orientam sua arquitetura de software e permitem que você conclua o projeto com um produto final com o qual suas partes envolvidas ficarão satisfeitas.

Sem uma compreensão clara desses requisitos desde o início, sua equipe corre o risco de se perder, enfatizando os requisitos errados em detrimento de outros, ou usando uma quantidade ineficiente de recursos internos. 

Obtenha uma melhor compreensão por meio de recursos visuais — siga estas etapas para mapear seus requisitos em uma plataforma de diagramação inteligente como o Lucidchart:

• Comece com uma visão de alto nível: esboce suas necessidades primeiro com uma "visão aérea". O mapeamento mental é uma maneira eficaz de fazer isso. 

• Mapeie seus requisitos funcionais: você pode usar verbos para ajudá-lo a agrupar substantivos. Por exemplo, verbos como “visualizar” e “editar” podem conectar “conta” ou “perfil” entre si em um mapa mental de áreas funcionais. 

• Leve em consideração os requisitos não funcionais: enquanto estiver trabalhando em seu mapa mental, você pode deixar seus requisitos não funcionais anotados para mais tarde. Um requisito como “desempenho” é fundamental, mas provavelmente é muito abstrato para ser colocado no mapa mental. 

Seus requisitos devem ser usados para moldar seu escopo de trabalho e planejar seu projeto.

2. Comece a pensar em cada componente

Sejamos sinceros: com a poderosa influência que seus requisitos funcionais têm em seu projeto, suas opções de desenho e tecnologia podem já estar decididas depois de você ter mapeado seus requisitos. 

Sem ir muito além de sua realidade pensando na implementação, você precisará descobrir quais requisitos representam desafios significativos para seu projeto ou plano de projeto. Alguns requisitos podem ser impossíveis sob certas suposições ou escolhas. 

• Comece com um “mundo perfeito”: como seria o seu desenho se você pudesse criá-lo perfeitamente? 

• Leve em consideração e documente as implicações de seus requisitos: inicie um rascunho de trabalho com sua equipe e desenvolva-o gradualmente. Primeiro, você pode querer ver o que seus requisitos significam para o seu desenho — por exemplo, onde itens individuais da lista de desejos das partes envolvidas podem se contradizer ou estar em conflito com outros requisitos funcionais e não funcionais. 

• Aguarde e desenhe a arquitetura final posteriormente: com toda a probabilidade, seu planejamento de arquitetura mudará ao longo desse processo, portanto, não espere que o primeiro rascunho se pareça com o resultado final. 

3. Divida sua arquitetura em fatias

Seu desenho de arquitetura passa naturalmente para uma fase de planejamento à medida que você decide como vai entregar em seu desenho. Dividir sua arquitetura em fatias pode ajudar você a elaborar esse plano de forma a agregar valor aos usuários e planejar adequadamente o uso dos recursos de desenvolvimento. 

Imaginar o corte de um bolo pode ajudar. A maioria das pessoas corta um bolo verticalmente, passando por cada camada. Digamos que uma fatia completa tenha cobertura, recheio e duas ou três camadas internas de pão de ló. Essa fatia vertical tem um pouco de cada coisa. Os bolos também podem ser cortados horizontalmente, separando as camadas individuais. 

Da mesma forma, se cada fatia é uma história usada para planejar sua arquitetura de software, então há camadas — fatiar o bolo verticalmente cria histórias centradas em características individuais, enquanto fatiar horizontalmente revela componentes individuais. Você precisa tanto de pensamento horizontal quanto vertical para seu projeto. 

A metodologia Ágil se concentra em fatias verticais, permitindo que sua equipe entregue valor rapidamente. Essa abordagem fornece aos clientes o progresso do produto rapidamente, e à equipe de desenvolvimento, o feedback sobre cada camada por trás de um recurso. Uma fatia vertical de sua arquitetura de software para um site de e-commerce pode ser o processo de fechamento do pedido. 

Em sua fatia de bolo vertical “fechar pedido”, você pode ver a camada de dados que armazena as informações sobre o fechamento do pedido, a camada intermediária da API e a camada superior da interface do usuário que os compradores veem. Com fatias verticais, você pode decidir quais recursos entregar e escolher peças iterativas.

Ao diagramar as camadas envolvidas em seu projeto de arquitetura de software, você pode visualizar a peça inteira e como cada camada influencia outras camadas. Conforme você planeja, pegue as fatias de bolo individuais da metodologia Ágil e faça um diagrama de como elas se conectam.

4. Criar um protótipo

Sempre crie um protótipo. Os protótipos permitem que você identifique falhas antecipadamente, fornecendo feedback rápido e permitindo que você descubra sua prova de conceito. Essa é uma parte importante de validar seu trabalho e verificar suas suposições para garantir que elas sejam válidas e completas. 

Ao criar seu protótipo, lembre-se de que as primeiras iterações nunca serão perfeitas, e nenhuma iteração final será completamente perfeita. Uma das vantagens da prototipagem é que ela não se configura um produto acabado, e a maioria das pessoas instintivamente entra em um processo de protótipo esperando pelo menos algumas arestas. 

Aproveite a fase de protótipo. Ela não substitui o teste, mas é uma parte crucial do teste que você precisa fazer. 

• Mantenha um histórico de revisão minucioso: é claro que, se você não documentar o que aprendeu com a prototipagem, corre o risco de repetir seus erros. Anote tudo — documente completamente suas decisões de desenho e as alterações feitas ao longo do caminho.

• Tenha uma única fonte de verdade: você não gostaria que várias alterações e versões diferentes desviassem seu progresso, então configure um controle de versão robusto focado em uma única fonte para sua documentação. 

• Diagrame seus protótipos: você pode usar diagramas para ajudá-lo a gerenciar alterações de protótipo e visualizar as diferenças entre cada versão. 

5. Identifique e quantifique requisitos não funcionais

Além dos requisitos funcionais, você terá requisitos não funcionais a serem levados em consideração. Esses requisitos são tão essenciais para o desenho quanto seus requisitos funcionais, porque eles definem as características do sistema. 

Os requisitos não funcionais geralmente são requisitos de qualidade de alto nível para todo o projeto, mas nem sempre. Seu sistema pode ter requisitos não funcionais específicos para apenas parte de sua arquitetura de software. Sendo assim, você precisa estar preparado para manter as partes envolvidas informadas sobre os requisitos locais não funcionais. Por exemplo, uma determinada fatia vertical do projeto pode interessar à equipe de atendimento ao cliente em particular, e essa equipe pode ter suas próprias expectativas sobre esses requisitos não funcionais.

No entanto, não basta dizer que você deseja desempenho, portabilidade ou escalabilidade. Requisitos não funcionais também devem ser quantificados. Nenhum projeto pode ter um desempenho absolutamente perfeito: o “desempenho” deve ser especificado e limitado para atender a outros requisitos. 

Como seus requisitos não funcionais desempenham um papel na modelagem do seu desenho, não tem como você escapar de defini-los. Aqui estão alguns outros requisitos que você pode levar em consideração:

• Desempenho: a qualidade do desempenho de todo o sistema, bem como das fatias ou camadas individuais

• Escalabilidade: o potencial atual e futuro para dimensionar seu sistema junto com suas necessidades

• Portabilidade: sua portabilidade de dados, bem como a potencial portabilidade dos componentes do seu sistema, se aplicável ou necessário

• Extensibilidade: levando em conta o crescimento futuro do seu sistema e da empresa, o quão bem seu sistema pode se adaptar e o esforço envolvido na adaptação

• Conformidade: outro fator essencial — e com um impacto considerável no desenho geral do projeto

Diagramar seus requisitos não funcionais pode ajudar sua equipe a ver como você os quantifica enquanto também coloca requisitos específicos em contextos relevantes. Embora você ainda não precise se preocupar em otimizar tudo, você também precisa considerar quais esforços e recursos podem ser necessários para otimizar esses requisitos não funcionais posteriormente. 

Práticas recomendadas para o desenho da arquitetura de software

Ao realizar seu projeto de desenho, essas práticas recomendadas ajudarão você a se manter fundamentado em bons princípios. 

Visualize seu desenho 

Usar recursos visuais em todo o trabalho de conceito de desenho, bem como em sua implementação, permite que sua equipe veja a perspectiva de alto nível por trás de seu desenho. Os diagramas são uma ótima maneira de visualizar processos e diferentes aspectos de suas escolhas de desenho.

Não escolha padrões 

Mantenha seu processo de desenho focado em um quadro mais amplo sem recorrer a padrões como ponto de partida. Em vez de usar padrões, mantenha-se no alto nível com uma visão geral dos componentes para reduzir o risco de engenharia excessiva de seus sistemas. 

Lembre-se de que o primeiro desenho é apenas a primeira iteração 

Com seu primeiro desenho, você está tendo uma ideia melhor dos desafios técnicos e dos obstáculos que enfrentará com o desenvolvimento de sua arquitetura. Não espere que o primeiro desenho seja nada mais do que um protótipo! 

Não se preocupe: seu desenho de arquitetura crescerá e se desenvolverá, permitindo que você descubra mais detalhes ao longo do tempo. 

Tenha cuidado com o aumento gradual do escopo 

Mesmo que pareça tentador permitir que seu escopo cresça, o aumento gradual do escopo ocorre às custas de seus outros requisitos e pode consumir os recursos necessários. Para interromper o aumento gradual do escopo, estabeleça um plano de projeto preliminar de trabalho que contabilize seus requisitos e converse com as partes envolvidas sobre os limites para requisitos não funcionais. Você não gostaria que alguma expectativa não atendida afetasse negativamente seu projeto. 

Tenha em mente os limites e as interfaces

Ao planejar seu projeto, pense nas interfaces entre os componentes e observe os limites do seu sistema. Comece a atribuir responsabilidades para que, ao trabalhar em seus protótipos e nas próximas iterações, tenha essas informações disponíveis para facilitar a referência.

Melhore seu desenho de arquitetura de software agora

O desenho da arquitetura de software é mais eficaz quando há um plano, contribuições das partes envolvidas e abordagem correta para delinear os requisitos para o projeto. Não economize nesse planejamento inicial e seus esforços podem ser recompensados com uma experiência de projeto mais tranquila.