Start here
Use this page as the default orientation path for new contributors.
Documentation structure
Baseleg docs are organized into four top-level sections:
Product
What Baseleg is, what it does, and v1 scope.
Domain
Bounded contexts, ubiquitous language, and DDD structure.
Architecture
Layering, packages, database, testing, and ADRs.
UX
Design tokens, components, patterns, and visual diagrams.
Quick links
System overview
How the modular monolith is shaped.
Package boundaries
Allowed vs forbidden dependencies.
Database
Where schema and migrations live and how to expand.
Context map
Bounded contexts and the v1 spine.
Definition of done
What "done" means for every feature in Baseleg.
UX system
Design tokens, components, patterns, and diagrams.
Recommended reading order
- Product overview — understand what Baseleg is and who it’s for.
- Domain overview — understand the DDD approach and bounded contexts.
- Context map + Ubiquitous language — learn the domain model.
- Architecture overview — understand the modular monolith and layering.
- Package boundaries — especially “no direct page → DB shortcuts”.
- Definition of done — understand what “complete” means.
- UX system — review design tokens, components, patterns, and visual diagrams.
- ADRs — understand the rationale behind key decisions.
Notes
- Data owner expands
db/schema/*, migrations, and infrastructure wiring over time. - If you change architecture boundaries or introduce major new tooling, add an ADR.
- Domain terms in code must match the ubiquitous language.