yknothing Data Modeling
Turn concepts and boundaries into durable data structures the system can evolve safely.
Context
Data modeling decides what the system remembers, how it relates, and how change propagates through storage over time.
See context and anti-pattern notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Define Data Ownership
For each major entity or aggregate, decide:
- which component owns the canonical record
- which components may cache or project it
- which fields are authoritative versus derived
- what must stay transactionally consistent versus eventually consistent
Step 2: Shape the Storage Model
Translate the domain into tables, collections, events, or documents based on access patterns and consistency needs. Keep read models and write models separate when the workload or boundary requires it.
Avoid schemas that blur service boundaries just because a join would be convenient.
Step 3: Model Lifecycle and Mutation Rules
Document:
- identifiers and uniqueness rules
- state transitions and retention rules
- soft delete, archival, and backfill expectations
- migration hazards for legacy or brownfield coexistence paths
Step 4: Test the Schema Against Real Change
Before finalizing, challenge the model with likely future operations:
- adding a field without downtime
- replaying or backfilling data
- migrating legacy records
- supporting partial rollout or coexistence during modernization
If the data model makes routine change unsafe, revise it now.
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
- Data ownership is explicit for every core entity
- Schema aligns with architecture boundaries and domain language
- Consistency and lifecycle rules are documented
- Brownfield or migration-sensitive paths are called out explicitly
- The model can evolve without avoidable downtime or unsafe backfills