Product Invariants¶
Status¶
Normative Business Domain Specification
Purpose¶
This document defines the non-negotiable invariants of the Product Domain.
Invariants are domain laws.
Policies may evolve. Specifications may evolve. Invariants must remain stable unless the Product Domain model is explicitly redesigned.
Product Identity Invariants¶
One Canonical Identity¶
A Product SHALL have exactly one Canonical Product Identity.
A Product MAY have an incomplete Canonical Product Identity during discovery.
A Product MUST NOT silently replace its Canonical Product Identity.
Identity Independence¶
Canonical Product Identity MUST remain independent from merchants, offers, prices, promotions, stock, feeds, frontend titles, SEO titles, WordPress, SQL storage and runtime metadata.
Identifier Invariants¶
An Identifier SHALL be evidence.
An Identifier SHALL NOT define a Product alone.
A Product MAY contain multiple Identifiers.
Conflicting Identifiers MUST create an explicit ProductConflict.
Unknown Identifier types MUST NOT be treated as trusted identifiers.
Observation Invariants¶
An Observation SHALL be evidence.
An Observation SHALL NOT be final truth.
An Observation MUST NOT mutate Canonical Product Identity directly.
Any identity change caused by Observations MUST go through an explicit domain decision.
Variant Invariants¶
A Variant SHALL belong to exactly one Product.
A Variant MUST NOT be shared by multiple Products.
A Variant MUST represent a version of the same Product.
If Variant attributes imply another real-world Product, the Product aggregate MUST reject it or create an explicit ProductConflict.
Conflict Invariants¶
Every contradiction between evidences MUST become an explicit ProductConflict.
A ProductConflict MUST be traceable.
A ProductConflict MUST expose the evidences that caused it.
A ProductConflict MUST NOT be resolved silently.
Consistency Invariants¶
Product consistency SHALL be derived from identity completeness, identifier coherence, observation coherence, variant coherence and unresolved conflicts.
Product consistency MUST NOT depend on SQL state, cache state, frontend state, runtime state or WordPress state.
Boundary Invariants¶
A Product SHALL NOT contain offer price, stock, discount or merchant ranking.
A Product SHALL NOT contain catalog navigation, frontend pagination or SEO rendering rules.
A Product SHALL NOT contain WordPress, HTTP, CLI, Docker or database-specific behavior.
Violation Model¶
When an invariant is violated, the Product Domain MUST choose one explicit outcome:
- reject the operation;
- create a ProductConflict;
- return a domain failure;
- emit a Product Domain event after state change.
A violation MUST NOT be ignored.
Invariant To Policy Flow¶
The Product Domain follows this conceptual flow:
Invariant -> Violation -> Policy -> Domain Event
Specifications may be used by Policies to detect whether an invariant would be violated.
Architecture Decision¶
Decision: CERTIFIED.
Product Invariants become the strictest normative contract of the Product Domain.
All future Product Policies, Specifications, Events, Tests and Contracts must remain consistent with this document.