| name | pc-domain-modeling |
| description | 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. |
| metadata | {"phase":"01-specification","inputs":["requirements-doc"],"outputs":["domain-model"],"prerequisites":["pc-requirements-engineering"],"quality_gate":"Domain model reviewed, ubiquitous language documented and agreed upon by team","roles":["architect","developer"],"methodologies":["all"],"effort":"medium"} |
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 and anti-pattern notes.
Inputs
I/O contract notes 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
