# Domain Modeling

> Build a project's domain model — challenge terms, pin down a ubiquitous language, write the gloss…

Build a project's domain model — challenge terms, pin down a ubiquitous language, write the glossary down. Use when defining domain terminology, resolving ambiguous terms, or another skill needs the shared vocabulary. Don't use for a single architectural decision (/to-adr) or explaining code (/zoom-out).

- Page: https://ss33.ai/skills/helderberto/domain-modeling-26708828467
- Publisher: helderberto
- Category: [Software Development](https://ss33.ai/skills/category/software-development-t44z8z) › [Developer docs & tooling](https://ss33.ai/skills/category/software-development-t44z8z/developer-docs-and-tooling-nich6w)
- License: MIT
- Source: https://github.com/helderberto/agent-skills/blob/445681fd215e649201f91d65492025f0803efc0a/skills/domain-modeling/SKILL.md

## Skill

SKILL.md: https://ss33.ai/api/v1/ss33/download/helderberto/domain-modeling-26708828467

# Domain Modeling

The *active* discipline of shaping the model — challenging terms, inventing edge-case scenarios, and writing vocabulary down the moment it crystallizes. Merely *reading* a glossary for vocabulary is a one-line habit any skill does; this skill is for when you're changing the model, not consuming it.

## Artifact

Maintain the project's glossary in its existing convention; a legacy `CONTEXT.md` counts. If there is none, create `GLOSSARY.md` at the repo root. A repo with several bounded contexts gets one glossary per context, plus a root `GLOSSARY-MAP.md` that points to each. Call the Skill tool with `to-adr` to record decisions that settle a term, so the *why* is preserved separately from the *what*.

## Ubiquitous language

One term, one meaning, used everywhere — prose, code, docs, and the glossary agree. For each term write:

- A crisp definition.
- An **Avoid** list of the rejected synonyms, so the same concept never travels under two names.

When the same word means two things, that ambiguity *is* the work — split it into two named terms and retire the overloaded one.

## Sharpen by stress

Invent edge-case scenarios that a term must survive. A definition that can't classify the edge case is still fuzzy — refine it until it can, then write it down immediately. Flag ambiguities you can't yet resolve; record the resolution once decided.

Completion: every term touched has a definition and an Avoid list, and every flagged ambiguity is either resolved or explicitly parked.