2.4 — Project Architecture

Architecture is how you think about a system before you build it — and how you navigate it after. You don’t need to draw it perfectly. You need a mental model good enough to make decisions.

The Three-Layer Mental Model

Every application, from a simple website to a complex AI system, has the same three layers:

┌──────────────────────────┐
│  PRESENTATION            │  ← What users see (UI, pages, buttons)
├──────────────────────────┤
│  LOGIC                   │  ← What happens when they click (rules, calculations, decisions)
├──────────────────────────┤
│  DATA                    │  ← Where information is stored and retrieved
└──────────────────────────┘

The frontend (from Phase 0) lives primarily in Presentation. The backend handles Logic and Data. When you’re planning a project, the first question is: which layer does this feature belong to?

Essential Architecture Terms

Term	Definition
Architecture	The high-level structure of how a system is organized — what pieces exist and how they connect
Component	A self-contained piece of an interface that can be reused (like a button, a card, a navigation bar)
Route	A URL path that maps to a specific page or action (/about, /settings, /api/users)
State	Data that can change over time and affects what the user sees (is the menu open? is the user logged in?)
Environment variable	A setting stored outside your code (usually in .env) so it can change between local and production without editing code
Monorepo	One repository containing multiple related projects
Microservice	Architecture where the system is split into small, independent services that communicate via APIs
Monolith	Architecture where everything lives in one application. Not a bad word — simpler, and often the right choice for smaller projects.

Monolith vs. Microservices

This is one of the most debated topics in software — and the answer is almost always: start with the monolith.

A monolith is simpler to build, simpler to debug, and simpler to deploy. Microservices add enormous operational complexity. You split into microservices when you have a specific scaling problem that a monolith can’t solve — not before.

YAGNI applies here: don’t build microservices you ain’t gonna need.

Where Environment Variables Fit

Environment variables belong to the Data layer in a different sense — they’re configuration data your application reads at startup. The .env file (introduced in Phase 0) stores these. Never commit .env to Git. Never hardcode secrets in your code.

---

Next: 2.5 — Git Workflow | Phase overview: Phase 2