Comparação
MapleSpire ou Structurizr: qual acompanha a governança de uma grande empresa?
O Structurizr e o MapleSpire se apoiam no modelo C4 e em um modelo de verdade, não em desenhos. Eles divergem em uma questão decisiva para uma grande organização: onde ficam os metadados compartilhados e quem consegue mantê-los atualizados.
O Structurizr brilha quando a arquitetura é código, escrito e revisado no Git por times de engenharia. O MapleSpire mira um repositório governado: um único conjunto de catálogos de tags e tecnologias para toda a organização, editável visualmente por todos que têm permissão.
Duas filosofias de modelagem
O Structurizr é uma ferramenta de “modelos como código”: a arquitetura é escrita em uma DSL textual, versionada no Git e publicada em um servidor que gera os diagramas. A documentação recomenda um workspace por sistema de software, mantido pelo time que o constrói.
O MapleSpire é um modelo visual compartilhado: objetos, relações e visões ficam em um banco de dados, são editados em conjunto em tempo real e continuam disponíveis offline. Os catálogos de tags e tecnologias são entidades da organização, não texto copiado em cada arquivo.
Nenhuma abordagem é melhor em termos absolutos. A diferença aparece quando cresce o número de times, sistemas e pessoas contribuindo.
Atribuir metadados: tags, tecnologias, versões, grupos
| Metadado | Structurizr | MapleSpire |
|---|---|---|
| Tags | Texto livre por elemento (tags "A,B"); estilos ligados ao texto da tag | Tags e grupos de tags definidos uma vez para a organização, referenciados por identificador |
| Renomear ou mesclar uma tag | Localizar e substituir em cada workspace | Renomear, mudar a cor, mesclar ou arquivar: aplicado em todo lugar, em todas as paisagens |
| Tecnologias | Texto livre (technology "Java") | Catálogo gerenciado: aliases, ícones claros e escuros, links de documentação |
| Ciclo de vida de uma tecnologia | Não modelado | Ativa, obsoleta, descontinuada ou mesclada; novas entradas passam por aprovação |
| Versão em uso | Você mesmo adiciona no texto ou em properties | Versão registrada em cada uso de uma tecnologia |
| Grupos e domínios | Grupos visuais declarados na DSL | Grupos que podem levar tags e tecnologias; domínios hierárquicos |
| Propriedades personalizadas | properties e perspectives (pares chave-valor livres) | Previstas no modelo, ainda não editáveis na interface |
No Structurizr, um elemento é descrito com as palavras-chave tags, technology, properties e perspectives. São textos livres, digitados elemento por elemento. Os archetypes fornecem valores padrão e os estilos se apoiam nas tags, mas não há um registro central que defina o que é uma tag ou uma tecnologia válida.
Na prática, “PostgreSQL”, “Postgres” e “postgresql 16” podem coexistir em workspaces diferentes. Renomear uma tag exige um localizar-e-substituir em todos os repositórios envolvidos, e nada impede o uso de uma tecnologia que a organização já descontinuou.
No MapleSpire, um objeto não guarda o texto de uma tag: guarda uma referência a uma tag definida uma única vez para a organização. As tecnologias vêm de um catálogo gerenciado, com aliases, ícones e ciclo de vida.
E os responsáveis?
A responsabilidade por um elemento (qual time responde por ele) costuma ser o primeiro metadado exigido por um processo de governança. No Structurizr, ela vai para uma propriedade livre, como uma chave owner, sem ligação com um diretório de times.
O MapleSpire já gerencia times para o controle de acesso, e o modelo prevê associar times responsáveis aos objetos. Essa atribuição ainda não está disponível na interface: preferimos dizer isso com clareza a prometer.
Atualizar uma vez, para todos
Para uma visão corporativa, o Structurizr sugere uma abordagem em três etapas: reunir os sistemas de software em um catálogo DSL compartilhado por URL, fazer cada workspace de time estender esse catálogo e então gerar uma paisagem geral. Essa paisagem é produzida por um administrador que baixa todos os workspaces, roda o gerador e publica o resultado. É uma cópia: precisa ser gerada de novo para refletir as mudanças seguintes.
No MapleSpire, tags e tecnologias ficam no banco de dados da organização. Uma alteração feita no console de administração aparece imediatamente em todas as paisagens, sem etapa de publicação. Dentro de uma paisagem, cada objeto existe uma única vez e cada diagrama faz referência a ele.
Duas ressalvas, por precisão. No MapleSpire, o modelo detalhado continua restrito a cada paisagem; só os catálogos são compartilhados por toda a organização. E cada uso de uma tecnologia mantém a revisão do catálogo com que foi registrado, para que uma mudança no catálogo nunca reescreva o histórico silenciosamente.
Controle de acesso e revisão de mudanças
O núcleo de código aberto do Structurizr server não tem autenticação nem controle de acesso por papéis: os workspaces são públicos. Papéis, SAML, LDAP e a API de administração vêm com os binários pré-compilados licenciados. Sua grande força está em outro lugar: como o modelo é código, cada mudança pode passar por um pull request, uma revisão e uma validação automatizada na integração contínua.
O código AGPL-3.0 do MapleSpire inclui papéis na organização, times com permissão de leitura ou escrita por paisagem, login único OIDC com Google ou Microsoft e um log de auditoria das ações administrativas. As mudanças são preparadas em rascunhos, com uma lista de alterações e um merge que detecta conflitos.
Limite atual: os rascunhos do MapleSpire ainda não têm uma etapa formal de aprovação antes do merge. Se a sua governança exige revisão obrigatória de cada mudança, o fluxo de pull requests do Structurizr é hoje mais rigoroso.
Qual escala melhor?
| Critério | Structurizr | MapleSpire |
|---|---|---|
| Vocabulário coerente entre times | Depende de disciplina e revisões | Garantido por catálogos únicos |
| Pessoas que não são desenvolvedoras | Precisam aprender a DSL e o Git | Edição visual, multiusuário, em tempo real |
| Visão geral atualizada | Paisagem gerada de novo sob demanda | Catálogos compartilhados ao vivo; modelo detalhado por paisagem |
| Revisão obrigatória de mudanças | Pull requests e CI | Rascunhos e merge, ainda sem aprovação formal |
| Controle de acesso e SSO | Binários licenciados | Incluídos no código aberto |
| Alta disponibilidade | Depende do armazenamento e da licença escolhidos | Sincronização em uma única instância por enquanto |
Se o seu desafio é fazer a organização inteira falar a mesma língua (as mesmas tags, tecnologias e versões) e trazer arquitetos, líderes de produto e times que não vivem no Git, o MapleSpire escala melhor para a governança.
Se a sua arquitetura já é gerenciada como código, quem contribui são desenvolvedores e a governança passa pela revisão de pull requests, o Structurizr continua sendo uma excelente escolha.
Migrar ou usar os dois
O MapleSpire importa um workspace Structurizr DSL e gera os diagramas C4 correspondentes. Ele também exporta para Structurizr DSL, Mermaid, JSON, CSV, SVG, PNG e Markdown, então você pode testar o MapleSpire em um workspace existente sem abrir mão dos seus arquivos.
Fontes
As afirmações sobre o Structurizr se baseiam na documentação oficial, consultada em 12 de outubro de 2026. Os recursos do MapleSpire descritos aqui são os do código publicado.