domain-modeling

Domain Modeling

Actively build and sharpen the project's domain model as you design. This is the active discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely reading the knowledge bundle's glossary for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)

File structure

The domain model lives in an Open Knowledge Format (OKF) knowledge bundle at knowledge/ in the repo root. Most repos have a single context:

knowledge/
├── index.md              ← bundle map (reserved: no frontmatter)
├── log.md                ← change history, newest first (reserved: no frontmatter)
├── glossary/             ← one file per term (the glossary)
│   ├── index.md
│   ├── order.md
│   └── customer.md
└── adr/                  ← one file per decision
    ├── index.md
    ├── adr-0001-event-sourced-orders.md
    └── adr-0002-postgres-for-write-model.md

For multiple bounded contexts, each context is a subdirectory inside the one bundle (knowledge/ordering/glossary/, knowledge/billing/glossary/, …) and knowledge/index.md is the context map. See CONTEXT-FORMAT.md.

Create files lazily — only when you have something to write. If no knowledge/glossary/ exists, create it when the first term is resolved. If no knowledge/adr/ exists, create it when the first ADR is needed. Whenever knowledge changes, update the concept AND append to knowledge/log.md.

Extending the bundle (new concept categories)

glossary/ and adr/ are the two categories every bundle has; spec/ (written by /to-spec) is the third canonical one. But OKF is an open format — type is a free field and the bundle is not limited to a fixed set of folders. When you meet a durable domain entity that genuinely fits none of them — a recurring kind of thing the project needs recorded in its own right — a new concept category is legitimate.