# architect-frameworks-hub Referência rápida de Well-Architected, TOGAF, C4, ArchiMate, DDD, 12-Factor e Cynefin - URL: https://fernando.moretes.com/open-source/architect-frameworks-hub - Markdown: https://fernando.moretes.com/open-source/architect-frameworks-hub/guide.md?lang=pt - GitHub: https://github.com/fernandofatech/ref-architect-frameworks-hub - Language: TypeScript - Topics: - Stars: 1 - Forks: 0 - Updated: 2026-09-29T16:40:23Z --- O Architect Frameworks Hub é um site em Next.js 16 que junta, numa página só, os sete frameworks que mais aparecem no meu trabalho de arquitetura: AWS Well-Architected, TOGAF ADM, C4, ArchiMate, DDD, 12-Factor e Cynefin, com resumos curtos e indicações práticas de uso. ## Por que este repositório existe A pergunta que eu mais ouço em revisão de arquitetura não é "qual framework é o certo?", é "qual framework serve para *esta* conversa?". Um comitê de risco quer ouvir sobre os pilares de segurança e confiabilidade do Well-Architected. Um time de produto discutindo fronteira entre serviços precisa de bounded context, não de fase B do TOGAF. Um diagrama para diretoria pede o nível Context do C4, não o nível Code. O problema prático é que cada um desses frameworks mora num documento diferente, com dezenas ou centenas de páginas. A especificação do TOGAF passa fácil de 200 páginas em PDF. Quando você precisa lembrar quais são os entregáveis da fase E ou comparar ArchiMate com C4 cinco minutos antes de uma reunião, abrir o PDF original não é opção. O README resume a premissa numa frase que eu repito bastante: **frameworks são ferramentas, não religião**. O hub existe para servir de consulta rápida, carregar rápido e ajudar a escolher o framework pelo contexto, e não para substituir a fonte oficial de nenhum deles. ## O que está coberto - **AWS Well-Architected:** os seis pilares e as perguntas de revisão de cada um. - **TOGAF ADM:** as fases A até H, com os entregáveis de cada fase. - **C4 Model e ArchiMate:** os quatro níveis do C4 (Context, Container, Component, Code) e as camadas Business, Application e Technology do ArchiMate. - **Domain-Driven Design:** bounded contexts, linguagem ubíqua e padrões táticos. - **12-Factor App:** checklist com interpretação pragmática, não só a lista dos doze fatores. - **Cynefin:** framework de decisão para ambientes complexos, útil antes de escolher qualquer um dos outros. ## Como ele funciona Não tem backend, banco nem API. É um front-end estático de referência, e foi uma escolha deliberada: conteúdo de consulta que muda poucas vezes por ano não justifica nenhuma peça que exija plantão. **Stack:** Next.js 16 com React 19, TypeScript 5 e Tailwind CSS 4. A aplicação fica no diretório `frontend/` do repositório, que é por isso que o quickstart começa com `cd frontend`. **Entrega:** o deploy é na Vercel e o DNS passa pela Cloudflare. A versão em produção responde em [frameworks.moretes.com](https://frameworks.moretes.com). **Esteira:** o README declara quatro workflows de GitHub Actions: CI, Frontend, Vercel e Security. Na prática, todo push passa por build e checagem de segurança antes de chegar em produção, o mesmo padrão que eu uso nos outros repositórios do portfólio. **Documentação operacional:** `OPERATIONS.md` e `SETUP.md` descrevem operação e configuração, `docs/architecture.md` cobre o desenho e `CONTRIBUTING.md` diz como propor mudança. Se você for fazer fork, comece por esses arquivos, não pelo código. O custo de manter isso é baixo justamente porque não tem estado: o que envelhece é o conteúdo, não a infraestrutura. Quando a AWS revisar o Well-Architected ou o The Open Group publicar outra edição do TOGAF, a manutenção é editar texto e abrir PR. ## Do push à consulta Fluxo de entrega e de leitura do hub. Não há componente com estado no caminho. ### 🔧 GitHub: esteira - Repositório frontend/ (ci) - Actions CI · Frontend · Security (ci) ### 📡 Cloudflare: DNS - DNS frameworks.moretes.com (network) ### ▲ Vercel: hosting - Next.js 16 React 19 · Tailwind 4 (frontend) ### Fluxos - dev -> repo: push / PR - repo -> ci: dispara build e checagens - ci -> app: deploy - reader -> dns: resolve o domínio - dns -> app: encaminha ## Rodar localmente 1. **Clone o repositório**: `git clone https://github.com/fernandofatech/ref-architect-frameworks-hub.git` e entre no diretório criado. 2. **Entre em frontend/**: A aplicação Next.js não está na raiz. Rodar `npm install` na raiz não instala nada útil e o erro não é óbvio. 3. **Instale as dependências**: `npm install`. Use uma versão de Node compatível com Next.js 16. 4. **Suba o servidor de desenvolvimento**: `npm run dev` e abra o endereço que o Next.js imprimir no terminal, normalmente `http://localhost:3000`. 5. **Antes de abrir PR**: Leia `CONTRIBUTING.md`. A esteira roda os workflows de CI e Security no seu PR, então build quebrado não passa. _Quickstart completo_ ```bash git clone https://github.com/fernandofatech/ref-architect-frameworks-hub.git cd ref-architect-frameworks-hub/frontend npm install npm run dev ``` ## Como eu uso no dia a dia O hub não decide nada por você. Ele encurta o caminho até a pergunta certa. Três usos que se repetem: **Antes de uma revisão de workload:** abro as perguntas de revisão do Well-Architected do pilar que mais preocupa naquele sistema. Em plataforma financeira quase sempre é segurança e confiabilidade, e ter as perguntas na tela evita que a revisão vire conversa genérica sobre "boas práticas". **Quando o problema ainda não tem forma:** começo pelo Cynefin. Se o domínio é complexo, e não só complicado, a resposta é experimentar e medir, e não sair desenhando a arquitetura-alvo com TOGAF. Escolher o framework errado nessa etapa custa semanas de documento que ninguém vai usar. **Na hora de desenhar:** C4 para conversa com time técnico e gestão, ArchiMate quando o público é arquitetura corporativa e precisa ligar processo de negócio a aplicação e infraestrutura. DDD entra quando a discussão é fronteira de serviço, e o checklist 12-Factor entra antes de qualquer coisa ir para container. > **Resumo não é fonte:** O hub é material de consulta rápida. Para auditoria, certificação ou qualquer decisão que vá ser cobrada depois, cite a fonte oficial: o AWS Well-Architected Tool e os whitepapers da AWS, a especificação do TOGAF no The Open Group, c4model.com. Resumo envelhece quando o framework muda, e ninguém avisa. ## Perguntas frequentes ### Preciso de conta AWS ou alguma credencial para rodar? Não. É um front-end Next.js sem backend. `npm install` e `npm run dev` em `frontend/` bastam. ### Posso usar o conteúdo internamente na minha empresa? O repositório é MIT. Os frameworks em si têm donos e licenças próprias (TOGAF e ArchiMate são do The Open Group, por exemplo), então confira os termos deles antes de redistribuir trechos das especificações originais. ### Por que não um wiki ou um Notion? Porque versionar em Git dá histórico, revisão por PR e a mesma esteira de CI e segurança dos outros projetos. O custo de hospedar na Vercel um site sem estado é praticamente zero. ## Referências - [GitHub: fernandofatech/ref-architect-frameworks-hub](https://github.com/fernandofatech/ref-architect-frameworks-hub) - [Architect Frameworks Hub (produção)](https://frameworks.moretes.com) - [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) - [The C4 model](https://c4model.com) - [The Twelve-Factor App](https://12factor.net) ## Para quem serve Use o hub quando você já conhece os frameworks e precisa de consulta rápida para escolher qual cabe na conversa da vez, ou quando quer um ponto de partida para montar a sua própria referência interna com fork. Ele não serve para aprender TOGAF do zero nem para embasar uma auditoria: aí o caminho é a especificação oficial. Para quem só precisa consultar, a versão em produção resolve sem clonar nada. ## Links - [GitHub repository](https://github.com/fernandofatech/ref-architect-frameworks-hub)