Diagramas de design de arquitetura

Os arquitetos geralmente se comunicam por meio de diagramas. Visuais bem projetados são uma ferramenta poderosa que ajuda implementadores, revisores de segurança e stakeholders de negócios a convergir em um modelo mental compartilhado, expor riscos anteriormente e reduzir o retrabalho. Para se comunicar com intenção, um arquiteto deve selecionar e geralmente tipos de diagrama de camada que correspondem à mensagem, ao público-alvo e ao estágio do ciclo de vida.

Por fim, a escolha do diagrama de arquitetura depende do que você está tentando transmitir e das perguntas do seu público. Os arquitetos usam vários tipos de diagramas em atividades de design, refinamento de requisitos e comunicação de stakeholders. Espere manter vários diagramas em previsão, elaboração de design, modelagem de ameaças, implementação, operações e governança.

Práticas de diagramação

Diagramas eficazes transmitem informações substanciais sem exigir uma explicação textual abrangente. Para evitar ambiguidade e garantir uma comunicação clara, siga estas recomendações:

Use notações padrão. Use símbolos, ícones e convenções de apresentação amplamente reconhecidos para garantir uma boa legibilidade e interpretação consistente entre diferentes públicos.

Evite linhas ambíguas. Diagramas geralmente mostram relações entre entidades usando linhas. Seja consistente em como você representa essas relações em todos os diagramas.

Use setas direcionais. Linhas sem setas não deixam as relações claras. Sempre use setas e, quando houver comunicação bidirecional, mostre dois fluxos separados (preferenciais) ou anota uma única seta com anotações de solicitação/resposta.

Evite setas bidirecionais. Setas duplas implicam dependências bidirecionais, o que pode criar confusão. Use setas de término único para representar o fluxo do componente iniciador (cliente) para a dependência (servidor).

Rotule tudo claramente. Forneça rótulos claros, precisos e significativos para cada ícone, contêiner de agrupamento e relação. Linhas de rótulo quando as relações não são imediatamente óbvias do contexto.

Manter a consistência. Use cores padronizadas, maiúsculas, ícones, tamanhos de ícone, pesos de linha, tipos de linha, setas e estilos de borda para elementos semelhantes. Aplique a mesma taxonomia em cada diagrama no conjunto de soluções. Extraia de padrões organizacionais ou taxonomias existentes.

Seja preciso. Embora os diagramas sejam abstrações, não sacrifique a precisão por simplicidade desnecessária. Por exemplo, não desmarque um serviço PaaS dentro de uma sub-rede se ele for realmente acessado por um ponto de extremidade privado. As imprecisões em diagramas podem levar a graves erros de falha de comunicação e implementação. Desativar diagramas que não respondem mais com precisão a uma pergunta do stakeholder ativo.

Inclua metadados. Verifique se cada diagrama contém metadados que fornecem contexto essencial sobre sua finalidade, escopo e significância. Inclua elementos como título, descrição, data da última atualização, autor, versão e referências externas. Essas informações ajudam os espectadores a entender a intenção e o frescor do diagrama. Depois que um diagrama é compartilhado amplamente pela primeira vez, a manutenção de um log de alterações vinculado ajuda os visualizadores a saber o que foi alterado.

Use ícones oficiais e nomes de serviço. Ao representar tecnologias específicas, sempre use os ícones oficiais mais recentes e as convenções de nomenclatura. Não estique ou recolora formas de marca arbitrariamente. Não substitua logotipos de marketing por elementos conceituais, por exemplo, usando logotipos de fornecedor para blocos de gateway de API genéricos.

Por exemplo, aqui estão os ícones dos serviços da Microsoft:

• Ícones da arquitetura do Azure
• Ícones do Microsoft 365
• Ícones do Microsoft Dynamics 365
• Ícones da arquitetura da ID do Microsoft Entra
• Ícones do Microsoft Fabric
• Ícones do Microsoft Power Platform

Forneça uma legenda. Se você introduzir semântica de borda ou linha, por exemplo, solid é uma chamada síncrona enquanto o traço é assíncrono, inclua uma legenda compacta.

Design para acessibilidade. Verifique o contraste de cores suficiente. Evite depender apenas da cor para distinguir tipos, em vez disso, emparelhe consistentemente a cor com o padrão.

Camada, não sobrecarregue. Resista à necessidade de codificar cada subsistema, classificação de dados e caminho de runtime em um único diagrama. Fornecer divulgação progressiva: um diagrama de contexto leva a um diagrama de contêiner, o que leva a um componente focalizado ou diagrama de sequência para um caso de uso crítico.

Controle de versão. Armazene arquivos de origem do diagrama no mesmo repositório ou repositório de documentação que os outros ativos com versão da carga de trabalho.

Tipos de diagramas de design

A arquitetura da carga de trabalho é complexa e multidimensional. Diferentes tipos de diagrama se concentram em aspectos específicos do sistema, fornecendo níveis de detalhes direcionados para cada dimensão. Por exemplo, fluxogramas ilustram o fluxo de processo, enquanto diagramas de relação de entidade mostram relações entre componentes do sistema.

O uso de diferentes tipos de diagrama permite uma compreensão abrangente em todas as dimensões arquitetônicas. Essa abordagem facilita a comunicação efetiva, a resolução de problemas e a tomada de decisões entre diversos stakeholders com diferentes origens técnicas e preocupações. Seus registros de decisão de arquitetura fazem referência a esses diagramas para visualizar a decisão.

Os tipos a seguir incluem artefatos comuns de comunicação de arquitetura de nuvem, além de várias adições de alto valor. A lista de tipos de diagrama não é exaustiva. Na prática, muitos artefatos são híbridos ou evoluem. Para visualizar sua carga de trabalho, favoreça um conjunto mínimo de diagramas propositals em vez de criar todos os tipos possíveis. Inicie exibições amplas, progressivamente estreitas e, em seguida, aplique cenários e exibições de corte cruzado.

Diagrama de contexto

Um diagrama de contexto apresenta a carga de trabalho como uma única caixa preta em seu ambiente externo. Ele nomeia o sistema, declara brevemente sua finalidade e mostra as personas externas, sistemas upstream e downstream e fontes de dados ou coletores que interagem com ele. Somente os caminhos de comunicação ou integração de alto nível são exibidos; A estrutura interna é deliberadamente omitida para que o público se concentre nos limites e dependências do escopo, não na implementação. Confie em formas genéricas para sistemas externos em vez de logotipos de produtos e sempre inclua um limite explícito para que os leitores não precisem inferir o escopo.

Diagrama de contêiner ou sistema de alto nível

Um diagrama de sistema de alto nível fornece uma visão geral ampla de uma carga de trabalho inteira ou uma subseção principal dentro de uma carga de trabalho. Ela decompõe a carga de trabalho em seus principais componentes, suas relações e o fluxo geral de dados por meio do sistema. Setas indicam a direção de interações e dependências.

Use esse diagrama após o alinhamento de contexto para expor a estrutura de macro, hospedar modelos como PaaS ou autogerenciada e dependências externas. Esses diagramas são excelentes para estabelecer um entendimento comum entre os stakeholders antes de se aprofundar em discussões técnicas mais profundas. Eles também são valiosos para comunicação executiva e de stakeholders, em que a compreensão de alto nível é mais importante do que os detalhes técnicos.

Diagrama funcional ou de bloco

Um diagrama de bloco divide uma carga de trabalho em recursos funcionais principais usando blocos independentes de tecnologia, concentrando-se na funcionalidade que está sendo executada em vez do componente específico.

Por exemplo, um diagrama de bloco pode fazer referência a uma fila de pedidos ou barramento de mensagens em vez de especificar uma tecnologia específica de barramento de mensagens, como o Barramento de Serviço do Azure ou o Apache Kafka. Esse nível de abstração ajuda a explicar a estrutura, o fluxo de dados e o fluxo de processamento de um sistema sem sobrecarregar o público com as especificidades de implementação, tornando-o ideal para discussões e coleta de requisitos de modelagem de domínio precoce.

Diagrama do componente

Um diagrama de componente se baseia em diagramas de bloco substituindo blocos funcionais genéricos por tecnologias específicas e pontos de integração. Ele apresenta uma exibição detalhada que comunica a tecnologia concreta do sistema e suas relações, como interações cliente-servidor. Esses diagramas servem como uma fatura visual de materiais para a arquitetura, mostrando exatamente quais tecnologias serão implementadas.

Diagrama de implantação

Um diagrama de implantação se concentra em como a infraestrutura, o software comercial off-the-shelf (COTS) e o código personalizado são implantados no ambiente de hospedagem. Ele mostra o mapeamento entre os componentes de software e a infraestrutura física ou virtual que os hospeda.

Esses diagramas são úteis para planejamento do DevOps, configuração do ambiente e compreensão dos aspectos operacionais da arquitetura. Elas ajudam as equipes a visualizar limites de dimensionamento, unidades de implantação, dependências de infraestrutura e ambientes.

Diagrama de fluxo de dados (DFD)

Um DFD (diagrama de fluxo de dados) ilustra como os dados movem, transformam, são armazenados e saem do sistema. Enfatize fontes, coletores, estágios de transformação, classificação (pública, confidencial, regulamentada) e se a movimentação é em lotes, streaming ou quase em tempo real. Ele ajuda com a análise de linhagem de dados, controles de governança e identificação de gargalo de desempenho.

A modelagem de ameaças à segurança, como o modelo STRIDE, usa um DFD especializado. O diagrama mostra processos, armazenamentos de dados, entidades externas, limites de confiança e fluxos de dados que ultrapassam esses limites. Ele se concentra em anotar fluxos com protocolos e criptografia e realça os ativos que exigem proteção. Esta ilustração impulsiona a identificação de mitigação e a validação do controle de segurança.

Diagrama de sequência

Um diagrama de sequência ilustra a ordenação temporal de interações para um único caso de uso ou cenário. Por exemplo, o usuário faz o pedido. Ele ilustra as relações cliente-servidor e mostra claramente se as interações são síncronas ou assíncronas. Esses diagramas também realçam dependências em padrões de comunicação e ajudam a avaliar possíveis cenários de falha nas interações de componente. Diagramas de sequência são particularmente valiosos para o design da API.

Diagrama de fluxo do usuário ou percurso

Um diagrama de fluxo de usuário mostra as etapas de ponta a ponta que um usuário ou persona executa entre interfaces e serviços. Ele visualiza o percurso do usuário pelo sistema, mostrando como os usuários e seus dados interagem com vários componentes e processos. Esses diagramas são úteis para esclarecer os requisitos funcionais, validar o design da experiência do usuário e garantir que todos os cenários de usuário sejam tratados corretamente na arquitetura. Anotar com expectativas de desempenho ou de nível de serviço em fluxos críticos.

Diagrama de relação de entidade (ERD)

Um diagrama de relação de entidade (ERD) representa a estrutura do modelo de dados lógico ou físico: entidades (tabelas e coleções), atributos, chaves e cardinalidades. Use ERDs lógicos para alinhamento de domínio e ERDs físicos para detalhes de implementação (índices, particionamento). Às vezes, detalhes adicionados, como intervalos de fragmentação, podem ser comunicados neste diagrama. Esses diagramas ajudam os desenvolvedores a entender as relações e restrições de dados antes do início da implementação.

Diagrama de conectividade de rede

Um diagrama de rede ilustra a carga de trabalho de uma perspectiva de infraestrutura de rede, mostrando onde os componentes se comunicam entre limites de rede. Esses diagramas visualizam a segmentação de rede, possíveis pontos de falha de rede e transições de rede críticas, como pontos de entrada e saída da Internet. Uma carga de trabalho pode se beneficiar de ter um diagrama de rede que se concentra no tráfego leste-oeste e em outro diagrama de rede para o tráfego norte-sul.

Diagramas de rede geralmente têm utilitário estendido além da fase de implementação inicial. Eles são frequentemente referenciados durante auditorias de segurança, revisões de conformidade e atividades de resposta a incidentes, tornando-os valiosos ativos de documentação de longo prazo.

Diagrama de estado

Um diagrama de estado é uma visualização especializada que mostra possíveis estados de um objeto de domínio, fluxo de trabalho ou subsistema. Ele inclui as condições ou eventos que disparam transições entre estados. Por exemplo, descrevendo como uma ordem progride do rascunho, enviado, revisado, atendido, para fechado.

Diagramas de estado ajudam a destacar possíveis preocupações de simultaneidade, tratamento de transição e compensação de necessidades de transação. Isso ajuda a reduzir a probabilidade de comportamentos de alteração de estado não previstos na produção.

Diagrama de fluxograma e atividade

Fluxogramas e diagramas de atividade trazem clareza para fluxos de trabalho complexos, lógica de decisão e processos de negócios dentro de sua carga de trabalho. Eles são úteis para representar processos de aprovação e cenários de ramificação condicional, o que ajuda você a documentar runbooks operacionais, automação de processos empresariais e fluxos de resposta a incidentes.

Outros diagramas especializados

Diagrama baseado em especificação

Existem várias especificações abertas nas quais você pode basear diagramas. Adotar uma é uma decisão da equipe de carga de trabalho; faça isso somente se ele adicionar vocabulário compartilhado necessário para reduzir a ambiguidade. Se sua abordagem de comunicação visual atual já funcionar, evite adicionar peso do processo apenas para formalidade. Mesmo quando você não adota uma especificação, o empréstimo seletivo de convenções comprovadas (camadas, notação de cardinalidade, rotulagem de eventos, padrões de legenda) pode gerar clareza e consistência em todo o conjunto de diagramas.

Exemplos de especificações de diagramação e modelagem:

• Modelo e notação do processo de negócios
• Modelo C4
• Modelo de decisão e notação
• UML (Unified Modeling Language)

Próximas etapas