# CommerceDex Architecture Docs — Overview

## What this document set is

This is the **Phase 1 deliverable** of CommerceDex: Product Vision & Domain Architecture. It establishes:

- What CommerceDex is, and what it deliberately is not (`01-product-vision.md`)
- The non-negotiable product principles and what they rule out (`02-principles-and-tradeoffs.md`)
- The reference technical architecture chosen to satisfy a cost-conscious, single-tenant self-hosting model (`03-reference-architecture.md`)
- The domain model: 20 bounded modules, their responsibilities, and how they relate (`04-domain-modules.md`)
- The rules governing how modules are allowed to talk to each other (`05-module-interaction-model.md`)
- Open questions and risks flagged for explicit sign-off before Phase 2 begins (`06-open-questions.md`)

## What this document set is NOT

- **Not a database schema.** Entities named here (Product, Order, Stock Level, etc.) are business concepts, not table definitions. Schema design belongs to Phase 3 — System Architecture & Database Design.
- **Not a UX/UI specification.** Screens, flows, and navigation belong to Phase 2 — Information Architecture & UX Flows.
- **Not a final technology commitment.** The stack named in `03-reference-architecture.md` proves the vision is cheaply feasible; it is explicitly revisited and hardened in Phase 3.
- **Not exhaustive implementation detail.** These docs describe boundaries and responsibilities, not algorithms, APIs, or code structure.

## How to read these docs

Read in order the first time (00 → 06). After that, treat `04-domain-modules.md` as the primary reference — it's the one you'll return to most often when building or reasoning about a specific area of the system.

## Relationship to later phases

| Phase | Depends on Phase 1 for |
|---|---|
| Phase 2 — Information Architecture & UX Flows | The module list and business language in `01` and `04` — screens should map to merchant goals within these bounded contexts, not to internal implementation seams. |
| Phase 3 — System Architecture & Database Design | The tiering and interaction rules in `04` and `05` — schema-per-module boundaries and the event/job mechanism are designed to enforce what's described here. |
| Phase 5+ — Commerce Core, Catalog & Inventory, etc. | The bounded-context definitions in `04-domain-modules.md` are the contract each module's implementation must honor. |

## Glossary

Business-language terms are defined inline where they first appear in `04-domain-modules.md` (e.g., what "Product" means in Catalog vs. Inventory vs. Orders). There is no separate glossary file in Phase 1 — introduce one only if term collisions become a recurring problem in later phases.