Architecture
Why model-first beats code-first
When the model leads, the code follows. A case for designing the domain before you reach for the database.
Most systems decay not because the code was bad, but because the model underneath it was never made explicit. The team reached for a framework, scaffolded some tables, and let the schema become the de facto design. For a few months that feels fast. Then the first awkward feature arrives — the one the schema can't express — and every change after it pays interest on that early shortcut.
The model is the real architecture
A model-first approach inverts the order. Before any table or endpoint exists, you describe the domain in plain language: the entities, the relationships, the rules that must always hold. The code becomes a faithful projection of that model rather than the other way around.
Code is the most expensive place to discover that your model was wrong.
This is not big-design-up-front in disguise. The model can be a single page, and it should change as you learn. The discipline is simply that it changes first, deliberately, rather than being reverse-engineered from whatever the ORM happened to generate.
What it buys you
- Cheaper change. When the model is explicit, the impact of a change is visible before you touch code.
- Shared language. Product, engineering and leadership argue about the same nouns.
- Better boundaries. Services split along seams in the model, not along team org charts.
None of this requires heavyweight tooling. It requires the willingness to spend an afternoon on the model that will otherwise cost you a quarter in the code. That trade is almost always worth making.