architect-frameworks-hub

After 16 years designing platforms on AWS, the question that burned the most meeting time was never "which framework should we use?" — it was "what exactly does this framework say about our case?". Well-Architected has six pillars, each with dozens of review questions; TOGAF ADM has eight phases, A through H, each with its own deliverables; C4 fits in four levels, yet half the meetings confuse a C4 Container with a Docker container. Every time a decision required comparing two of them, someone reopened the 200-page PDF.

This repository is the reference I wish I had: a static, fast site that condenses each framework — phases, pillars, layers, checklist — with pointers to the official source when the detail matters. It does not replace the original material. It replaces the time lost digging through it.

What it is not: it is not a course, not a certification prep, and not a ranking of which framework is "best". Frameworks are tools, not religion. The hub exists so you can pick the right tool for the context and explain the trade-off to whoever decides, without going back to chapter 12.

The app lives in the frontend/ directory: Next.js 16 with the App Router, React 19, TypeScript 5 and Tailwind CSS 4. The framework content is the part that matters; the stack only has to deliver it fast and with no operational cost. That is why the site is static, hosted on Vercel, with DNS on Cloudflare. No database, no API, no server state. The monthly cost of keeping it up is zero — and it is the cost of maintaining, not building, that decides whether a reference project survives past its first year.

Three GitHub Actions workflows guard the repository — CI, Frontend and Security — and the badges at the top of the README reflect the current state of each. The rule that applies to every contribution: if npm run build fails in CI, the change does not land, however correct the prose is.

Operational docs: docs/architecture.md describes the project structure; OPERATIONS.md and SETUP.md cover configuring and operating the site (domain, deploy); CONTRIBUTING.md explains how to propose content changes — the most useful kind of contribution here. MIT licensed.

The hub's value is in crossing the frameworks, not in reading each one in isolation. The sequence I follow when a new problem lands:

Classify with Cynefin before picking a method: an event pipeline with known business rules is a complicated domain — analysis and good practice apply. A new product with no users yet is complex — experiments apply, not an eight-phase plan.

TOGAF ADM when the change crosses the organization: phases A through H make sense for a transformation with several business areas, executive sponsorship and a multi-year horizon. For a single service, the ADM is dead weight.

C4 to communicate, ArchiMate to govern: C4 in four levels is what fits in a 30-minute meeting with engineering. ArchiMate, with its three layers, is what an enterprise architecture office can keep as a living repository.

DDD when the domain model is the risk: bounded contexts and ubiquitous language solve the problem of two teams meaning different things by "customer". If the domain is CRUD, DDD is ceremony.

Well-Architected and 12-Factor as the review checklist: the six pillars for the AWS workload, the twelve factors for the service headed to a container. Those are the two I open every time before something goes to production.