When the business model should reshape the schema

Generic CRUD schemas look tidy in a demo and fall apart the first time a product constraint shows up: cooling-off periods, partial fills, or a report that must reconcile to the rupee.

Domain language over table convenience

At Paytm lending surfaces and later in trading work, the useful questions were rarely “which ORM feature should we use?” They were:

• What is the unit of money movement the business recognizes?
• What states can this entity enter that finance or compliance will ask about later?
• What happens when the happy path is interrupted mid-flight?

Those answers belong in the model. If they only live in Slack and tribal knowledge, every new engineer relearns them by breaking production.

Architecture follows the model

Once the domain language is sharp, service boundaries get easier. You stop splitting systems by whatever framework was fashionable that year and start splitting by the decisions the business actually makes.

That is the thesis behind this site’s writing: the stack is the easy part. The model is where product judgment shows up as engineering.