# Pc Domain Modeling

> Use when reviewed requirements still carry ambiguous business nouns, overlapping concepts, or possible bounded contexts, and the team needs a shared domain model before spec writing, API design, or data modeling.

- Skill: `yknothing/pc-domain-modeling` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add yknothing/pc-domain-modeling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yknothing/pc-domain-modeling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: yknothing (https://skillmd.com/u/yknothing)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yknothing/pc-domain-modeling

---


# Domain Modeling

> Model the business language before modeling storage, APIs, or implementation.

## Context

Domain modeling turns reviewed requirements into a stable business-language contract.

See [context](references/context.md) and [anti-pattern](references/anti-patterns.md) notes.

## Inputs

[I/O contract notes](references/io-contract.md) define required inputs and authority.

## Process

### Step 1: Identify Core Entities

Extract the nouns and verb phrases that represent real business concepts:

- campaign
- reviewer assignment
- evidence package
- policy exception

Prefer concepts from the problem space, not solution-space placeholders like table, queue, endpoint, or job.

### Step 2: Define Relationships

Map how entities relate and where the relationship is authoritative:

- one-to-one / one-to-many / many-to-many
- optional vs required
- source-of-truth vs derived view
- transitional or compatibility-only relationship when brownfield coexistence is in play

### Step 3: Establish Ubiquitous Language

Create a glossary of domain terms with precise definitions. Resolve synonyms:
- Is "Customer" the same as "User"? If not, what's the difference?
- Is an "Order" created when the user clicks "Buy" or when payment succeeds?

Record legacy or tenant-specific terms separately when they must remain visible but should not silently dominate the new model.

### Step 4: Identify Bounded Contexts

Introduce bounded contexts only when the requirements justify a real language or responsibility split:
- **Order Context**: Order, LineItem, Discount
- **Payment Context**: Payment, Refund, Invoice
- **User Context**: Account, Profile, Preferences

Do not force DDD vocabulary onto a simple slice that only needs one coherent domain model.

### Step 5: Validate with Domain Experts

Walk the model against real scenarios from the requirements:

- happy path
- error or exception path
- brownfield or compatibility boundary

The model should make those scenarios easier to explain without leaking into schema or endpoint design.

## Outputs

Produce only declared outputs at their documented quality boundary.

## Quality Gate

- [ ] Core entities and relationships documented visually (ER diagram or similar)
- [ ] Ubiquitous language glossary created with team agreement
- [ ] Bounded contexts identified (if system is complex enough to warrant them)
- [ ] Model validated against at least 3 real business scenarios

## Distribution

- Public install surface: `skills/.curated`
- Canonical authoring source: `skills/01-specification/pc-domain-modeling/SKILL.md`
- This package is exported for `npx skills add/update` compatibility.
- Packaging stability: `beta`
- Capability readiness: `beta`
- Portability: `portable_with_caveat`
- Public caveat: Portable as skill guidance; full governance guarantees require the Prodcraft repository contracts and validation checks.