Se você já abriu um diagrama no Draw.io e saiu arrastando caixinhas e setinhas, você não está sozinho.
Mas o problema é que a maioria dos desenhos de arquitetura falha no ponto mais importante: comunicação.
Um bom desenho não serve só pra explicar o sistema — ele serve pra alinhar decisão, mostrar impacto e reduzir risco.
Guarde essa frase: 🧠 Desenhos de Arquitetura: não é sobre ficar bonito, é sobre comunicar com intenção.
Aqui vão algumas dicas que fazem MUITA diferença e que quase ninguém lembra 👇
🎯 Comece pelo objetivo (não pela ferramenta)
Antes de começar o desenho, responda:
- Esse desenho é pra quem?
- Dev?
- Produto?
- Stakeholder?
- Qual decisão ele precisa apoiar?
💡 Exemplo:
- “Explicar fluxo de pagamento” ≠ “mostrar impacto de uma refatoração”
Se você não sabe o objetivo, o desenho vira só decoração.
👥 Público-alvo muda tudo
O mesmo sistema pode ter vários desenhos diferentes:
| Público | Tipo de desenho |
|---|---|
| Devs | Fluxo detalhado, integrações, contratos |
| Negócio | Visão macro, blocos simples |
| Infra | Deploy, rede, escalabilidade |
👉 Um erro clássico: fazer um único diagrama tentando servir todo mundo.
Resultado: ninguém entende direito.
🧩 Desenhe impacto (quase ninguém faz isso)
Esse é o ponto mais subestimado.
Quando você está propondo mudança, seu desenho deveria responder:
- O que entra?
- O que sai?
- O que muda?
💡 Use padrões visuais simples:
- 🟢 Novo componente
- 🔴 Removido
- 🟡 Alterado
Isso transforma o desenho de “explicação” em ferramenta de decisão.
🔄 Mostre o antes e depois
Um único desenho não conta a história completa.
👉 Faça dois:
- Estado atual (AS-IS)
- Estado futuro (TO-BE)
Isso evita:
- Discussões abstratas
- Falta de clareza sobre impacto real
- Subestimação de esforço
🧠 Evite over-engineering no desenho
Arquitetura simples merece desenho simples.
Se você precisa explicar demais o diagrama, ele já falhou.
Evite:
- 20 tipos de setas diferentes
- Ícones sem legenda
- Misturar nível de abstração
🧱 Separe por níveis (não misture tudo)
Misturar tudo em um único desenho é outro erro comum.
Separe em níveis:
- Contexto (visão geral)
- Containers (serviços, APIs)
- Componentes internos
- Fluxos específicos
💡 Aqui você pode se inspirar no modelo C4 (sem precisar ser dogmático).
🔍 Destaque o fluxo crítico
Nem todo fluxo é igual.
Se existe um fluxo importante (ex: pagamento, criação de pedido), deixe isso claro:
- Numere etapas
- Use cores
- Direcione o olhar
👉 Isso ajuda MUITO em revisão técnica.
⚠️ Inclua riscos e pontos de atenção
Quase ninguém coloca isso no desenho — mas deveria.
Exemplos:
- Dependência externa crítica
- Gargalo
- Ponto único de falha
- Processo assíncrono sensível
💡 Pode ser só um ⚠️ com anotação. Já muda tudo.
🧾 Sempre coloque contexto mínimo
Um bom desenho responde sozinho:
- Nome do sistema
- Versão / data
- Autor (ou time)
- Escopo (o que está dentro e fora)
Sem isso, o diagrama envelhece mal.
🛠️ Ferramenta não importa (mas clareza sim)
Você pode usar:
- Draw.io
- Miro
- Lucidchart
- ArchiMate
Nenhuma delas vai salvar um desenho mal pensado.
Arquitetura boa não depende da ferramenta — depende da intenção.
🚀 Conclusão
Desenho de arquitetura não é arte.
É uma ferramenta de alinhamento e decisão.
Se o seu diagrama não deixa claro impacto, fluxo e mudança, ele provavelmente está só ocupando espaço.
Nesta primeira parte, o foco foi em dicas práticas para montar desenhos de arquitetura mais úteis. Na parte 2, vou trazer um exemplo prático de como aplicar isso no dia a dia.