Owning Your Data Model: The Architecture That Survives
Every layer of a software product has a different half-life. UI frameworks churn yearly. LLM providers deprecate models on a roadmap you do not control. But your data model — the entities, relationships, and invariants that describe your business — is the part you will live with for years. Design it like you mean it.
Model the business, not the screen
A common failure is to shape the database around the first UI. Screens are the most volatile part of any product. When you model entities around what the business actually is — accounts, work, events, money — your schema absorbs UI changes instead of breaking with them.
Make invalid states unrepresentable
The cheapest bug is the one the schema makes impossible. Use constraints, enums, and foreign keys to encode the rules of your domain at the storage layer. Application code is where rules go to be forgotten; the database is where they go to be enforced.
- Prefer explicit status enums over free-text fields.
- Encode required relationships as non-null foreign keys.
- Push uniqueness and ranges into constraints, not just validation code.
Keep the AI layer at the edge
When you add LLM integrations, resist the urge to let model output flow directly into your core tables. Treat generated content as untrusted input: validate it, structure it, and persist it through the same invariants as any other write. The model is a fast, fallible collaborator — your data model is the system of record.
Frameworks are rented. Models are rented. Your data model is the thing you own.
Get this layer right and everything above it becomes cheaper to change. That is the quiet leverage of good architecture: it does not show up in the demo, but it shows up in every quarter that follows.