85 lines
1.3 KiB
Markdown
85 lines
1.3 KiB
Markdown
# Enums (Shared Contract)
|
|
|
|
This document defines how enums are modeled, placed, and used across the system.
|
|
|
|
Enums are frequently a source of architectural leakage. This contract removes ambiguity.
|
|
|
|
## 1) Core principle (non-negotiable)
|
|
|
|
Enums represent knowledge.
|
|
|
|
Knowledge must live where it is true.
|
|
|
|
## 2) Enum categories (strict)
|
|
|
|
There are four and only four valid enum categories:
|
|
|
|
1. Domain enums
|
|
2. Application workflow enums
|
|
3. Transport enums (HTTP contracts)
|
|
4. UI enums (website-only)
|
|
|
|
## 3) Domain enums
|
|
|
|
Definition:
|
|
|
|
- business meaning
|
|
- affects rules or invariants
|
|
|
|
Placement:
|
|
|
|
- `core/**`
|
|
|
|
Rule:
|
|
|
|
- domain enums MUST NOT cross a delivery boundary
|
|
|
|
## 4) Application workflow enums
|
|
|
|
Definition:
|
|
|
|
- internal workflow coordination
|
|
- not business truth
|
|
|
|
Placement:
|
|
|
|
- `core/**`
|
|
|
|
Rule:
|
|
|
|
- workflow enums MUST remain internal
|
|
|
|
## 5) Transport enums
|
|
|
|
Definition:
|
|
|
|
- constrain HTTP contracts
|
|
|
|
Placement:
|
|
|
|
- `apps/api/**` and `apps/website/**` (as transport representations)
|
|
|
|
Rules:
|
|
|
|
- transport enums are copies, not reexports of domain enums
|
|
- transport enums MUST NOT be used inside Core
|
|
|
|
## 6) UI enums
|
|
|
|
Definition:
|
|
|
|
- website presentation or interaction state
|
|
|
|
Placement:
|
|
|
|
- `apps/website/**`
|
|
|
|
Rule:
|
|
|
|
- UI enums MUST NOT leak into API or Core
|
|
|
|
## 7) Final rule
|
|
|
|
If an enum crosses a boundary, it is in the wrong place.
|
|
|