# architect-frameworks-hub Sete frameworks de arquitetura em uma referência rápida, sem reabrir o PDF de 200 páginas - 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-08T20:45:45Z --- Um hub de referência em Next.js 16 que resume AWS Well-Architected, TOGAF ADM, C4, ArchiMate, DDD, 12-Factor e Cynefin no nível de detalhe que uma conversa de arquitetura exige — e nada além disso. ## Por que existe Em 16 anos desenhando plataformas sobre AWS, a pergunta que mais consumiu tempo de reunião não foi "qual framework usar?" — foi "o que exatamente esse framework diz sobre o nosso caso?". O Well-Architected tem seis pilares, cada um com dezenas de perguntas de revisão; o TOGAF ADM tem oito fases, de A a H, cada uma com entregáveis próprios; o C4 cabe em quatro níveis, mas metade das reuniões confunde *Container* do C4 com contêiner Docker. Toda vez que uma decisão exigia comparar dois deles, alguém reabria o PDF de 200 páginas. Este repositório é a referência que eu queria ter tido: um site estático, rápido, que resume cada framework — fases, pilares, camadas, checklist — com ponteiros para a fonte oficial quando o detalhe importa. Ele não substitui o material original. Substitui o tempo perdido procurando nele. **O que ele não é:** não é curso, não é preparatório de certificação e não é ranking de qual framework é "melhor". Framework é ferramenta, não religião. O hub existe para você escolher a ferramenta certa para o contexto e explicar o trade-off a quem decide, sem voltar ao capítulo 12. ## O que está coberto - **AWS Well-Architected:** os seis pilares e as perguntas de revisão que uso antes de qualquer carga ir para produção. - **TOGAF ADM:** fases A a H com os entregáveis de cada uma — o suficiente para saber em qual fase a sua transformação está. - **C4 Model:** Context, Container, Component e Code, com a distinção que evita a confusão clássica com Docker. - **ArchiMate:** camadas de Negócio, Aplicação e Tecnologia para quem precisa manter um repositório de arquitetura corporativa. - **Domain-Driven Design:** bounded contexts, linguagem ubíqua e os padrões táticos, sem a cerimônia que o DDD ganhou fora dos livros. - **12-Factor App e Cynefin:** o checklist dos doze fatores com leitura pragmática, e o framework de decisão para classificar o problema antes de escolher método. ## Como é construído O app vive no diretório `frontend/`: Next.js 16 com App Router, React 19, TypeScript 5 e Tailwind CSS 4. O conteúdo de cada framework é a parte que importa; a stack só precisa entregá-lo rápido e sem custo de operação. Por isso o site é estático, hospedado na Vercel, com DNS no Cloudflare. Não há banco, não há API, não há estado de servidor. O custo mensal de manter isso de pé é zero — e é o custo de manter, não o de construir, que decide se um projeto de referência sobrevive mais de um ano. Três workflows no GitHub Actions guardam o repositório — CI, Frontend e Security — e os badges no topo do README refletem o estado atual de cada um. A regra que vale para qualquer contribuição: se o `npm run build` quebra no CI, a mudança não entra, por mais correto que o texto esteja. **Documentação operacional:** `docs/architecture.md` descreve a estrutura do projeto; `OPERATIONS.md` e `SETUP.md` cobrem configuração e operação do site (domínio, deploy); `CONTRIBUTING.md` diz como propor mudança de conteúdo — que é o tipo de contribuição mais útil aqui. Licença MIT. ## Como o hub chega ao leitor Site estático: o leitor entra pelo DNS do Cloudflare e recebe páginas pré-renderizadas da Vercel; contribuições passam pelos workflows antes de virar deploy. ### 🌐 Cloudflare — DNS - frameworks.moretes.com DNS (network) ### ▲ Vercel — Hosting - Next.js 16 App Router · React 19 (frontend) - 7 páginas de framework estáticas · Tailwind 4 (storage) ### 🔧 GitHub — Repo & Actions - ref-architect-frameworks-hub frontend/ (data) - CI typecheck + build (ci) - Security varredura (security) - Frontend deploy (ci) ### Fluxos - reader -> dns: HTTPS - dns -> app: resolve para a Vercel - app -> pages: serve - contributor -> repo: push / PR - repo -> ci: a cada push - repo -> sec: a cada push - repo -> fe: em main - fe -> app: deploy ## Rodar localmente e contribuir 1. **Clone o repositório** — `git clone https://github.com/fernandofatech/ref-architect-frameworks-hub.git`. Todo o código do site está em `frontend/`; a raiz guarda a documentação operacional e os workflows. 2. **Instale as dependências** — `cd frontend && npm install`. Exige Node.js compatível com Next.js 16 — use a versão LTS atual. Não há variável de ambiente obrigatória para desenvolvimento: o site não chama serviço externo. 3. **Suba o servidor de desenvolvimento** — `npm run dev` e abra `http://localhost:3000`. Cada framework tem a própria página; edite o conteúdo e o hot reload mostra a mudança sem reiniciar. 4. **Prove o build antes de abrir PR** — `npm run build` roda o mesmo que o workflow de CI. Se passa local, passa no Actions. Leia `CONTRIBUTING.md` antes: mudança de conteúdo precisa citar a fonte oficial do framework — referência sem fonte é o pior defeito possível numa página de referência. 5. **Deploy é automático** — Merge em `main` dispara o workflow Frontend e a Vercel publica. `SETUP.md` e `OPERATIONS.md` descrevem o que fazer se você quiser hospedar a sua própria cópia, incluindo domínio e DNS. _Quickstart — do clone à página aberta_ ```bash git clone https://github.com/fernandofatech/ref-architect-frameworks-hub.git cd ref-architect-frameworks-hub/frontend npm install npm run dev # http://localhost:3000 # antes de abrir PR — o mesmo que o CI roda npm run build ``` ## Como uso na prática O valor do hub está em cruzar os frameworks, não em ler cada um isolado. A sequência que sigo quando um problema novo chega: **Classifique com Cynefin antes de escolher método:** um pipeline de eventos com regra de negócio conhecida é um domínio *complicado* — cabe análise e boas práticas. Um produto novo sem usuário ainda é *complexo* — cabe experimento, não plano de oito fases. **TOGAF ADM quando a mudança atravessa a organização:** fases A a H fazem sentido para transformação com várias áreas, patrocínio executivo e horizonte de anos. Para um serviço só, o ADM é peso morto. **C4 para comunicar, ArchiMate para governar:** C4 em quatro níveis é o que cabe numa reunião de 30 minutos com engenharia. ArchiMate, com as três camadas, é o que um escritório de arquitetura corporativa consegue manter como repositório vivo. **DDD quando o modelo de domínio é o risco:** bounded contexts e linguagem ubíqua resolvem o problema de dois times chamarem "cliente" coisas diferentes. Se o domínio é CRUD, DDD é cerimônia. **Well-Architected e 12-Factor como checklist de revisão:** os seis pilares para a carga na AWS, os doze fatores para o serviço que vai para contêiner. São os dois que abro toda vez antes de algo ir para produção. > **O erro mais caro não é escolher o framework errado:** É aplicar um inteiro onde meia página resolvia. TOGAF ADM num time de cinco pessoas custa dois sprints de documentação que ninguém vai ler; pular o Well-Architected porque "é só um MVP" custa a revisão de segurança que aparece seis meses depois, já em produção. O hub é curto de propósito: use o resumo para decidir a profundidade, e só depois abra a fonte oficial. ## Perguntas frequentes ### Preciso de conta AWS ou de alguma credencial para rodar? Não. O site é estático e não chama serviço externo em desenvolvimento nem em produção. `npm install` e `npm run dev` são o setup inteiro. ### Isso substitui o material oficial ou a certificação? Não, e não tenta. Cada seção aponta para a fonte oficial. O hub resolve o problema de lembrar a estrutura e comparar frameworks em minutos — o detalhe normativo continua no documento original. ### Posso propor outro framework? Sim, via PR seguindo `CONTRIBUTING.md`. O critério que aplico: o framework precisa aparecer em decisão real de arquitetura, ter fonte oficial estável e caber no mesmo formato de resumo mais ponteiros. Sem os três, ele vira ruído na navegação. ### Por que Next.js para um site sem back-end? Porque é a mesma stack do restante do portfólio — o custo de manter uma segunda ferramenta de build por anos supera o ganho de um gerador mais leve. As páginas são estáticas na Vercel; o framework só entra no build. ## Referências - [fernandofatech/ref-architect-frameworks-hub (GitHub)](https://github.com/fernandofatech/ref-architect-frameworks-hub) - [Architect Frameworks Hub — site em produção](https://frameworks.moretes.com) - [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) - [The C4 Model for visualising software architecture](https://c4model.com) - [The Twelve-Factor App](https://12factor.net) - [The Open Group — TOGAF Standard](https://www.opengroup.org/togaf) - [The Open Group — ArchiMate Forum](https://www.opengroup.org/archimate-forum) ## Para quem é Use este hub quando você precisa comparar dois ou mais frameworks numa mesma decisão, explicar um trade-off para quem não vai ler o PDF, ou revisar uma carga antes de produção com um checklist que cabe numa tela. Ele serve a arquitetos de solução, tech leads e engenheiros que tomam decisão de estrutura sem ter um escritório de arquitetura corporativa por trás. Não serve para estudar para certificação, nem para quem precisa do texto normativo — para isso, siga os ponteiros até a fonte. Se o seu time só usa um framework e o conhece de cor, o hub não acrescenta nada; se alterna entre três ou quatro dependendo do contexto, ele economiza a tarde que você gastaria reabrindo cada um. ## Links - [GitHub repository](https://github.com/fernandofatech/ref-architect-frameworks-hub)