Topic
Data & Persistence
Data models, databases, query models, and persistence decisions grounded in operations.
Keep Operational Tables Clean by Building a Separate Query Model
Design operational tables around business concepts, then serve complex history and admin searches from a separate query model.
Enums or Code Tables? Let the Rate of Change Decide
Use enums for stable values and focused tables for frequently changing ones without turning one common-code table into a dumping ground.
One Database, Separate Boundaries: Controlling Data Access by Domain
How separate entity and repository boundaries can protect core rules from integration code even when both areas share one database table.
Append, Don’t Overwrite: Designing Immutable Operational Data
An append-only repayment example that makes history and synchronization clearer, along with the storage and query costs it introduces.
Nullable or Zero? Choosing a Kotlin JPA Entity ID Strategy
Compare nullable and zero-valued numeric IDs for Kotlin JPA entities, including new-entity detection, ambiguity, and verification.
Track Database Changes with the Work That Ships Them
Collect database changes with the issue and PR that need them, test them in development, and hand off the final release set before code deployment.
Design for Change with Core Ownership and Surrogate Keys
Centralize a shared registration rule in the core, escalate isolation only when needed, and keep changing business uniqueness out of the primary key.
Rebuild First, Migrate Second
Design a replacement system around the problems it must solve, then handle legacy data through explicit migration mappings and retirement conditions.
Modeling Reactions from Requirements to Scale
Turn a vague like-button request into a reaction model by clarifying policy, estimating data growth, and planning when count queries must change.
Reversible Design Is the Antidote to Overengineering
Build the requirement in front of you, look only a little beyond it, and keep speculative structures cheap to expand, remove, or replace.
Foreign Keys Are an Operational Tradeoff, Not a Rule
Choose foreign keys, indexes, and ORM mappings from integrity needs, incident response, deployment practice, and who operates the database.
Reliable Database Tests Without a Shared Test Database
Choose mocks, an in-memory database, Testcontainers, or a real database by the failure you need to catch, while keeping ordinary tests isolated from shared infrastructure.
Choose Normalization from Requirements and Object Relationships
Database normalization is not a score to maximize. Decide from change semantics, query cost, and the relationships the data is meant to preserve.