🔫Why You Suck at Structuring Data And How to Finally Get Better 💪

Source: Dev.to

1. You think in UI, not in domain

Most devs start from a Figma screen or a quick whiteboard sketch — but rarely from actual business logic.

They ask:

“What JSON do I need for this response?”

instead of:

“What does the underlying domain really look like?”

So the API becomes a reflection of the UI, not of the business.

Your tables, models, and routes start to smell like:

• subtitle
• isCollapsed
• displayOrder
• object.with.20.levels.of.depth

That’s not data modeling. That’s serializing your component tree.

2. You merge unrelated concepts “because it’s easier”

You know this one:

{
  "user": { /* ... */ },
  "orders": [ /* ... */ ],
  "permissions": [ /* ... */ ],
  "stats": { /* ... */ }
}

Congratulations. You’ve created a blob API — a JSON smoothie. It works for one screen. It dies everywhere else.

3. You don’t separate stable vs unstable structures

UIs change weekly. Business rules change yearly.

If your API breaks every time someone moves a card in Figma or a customer requests a “tiny change”… you didn’t build an API. You built a UI transport layer.

A good data model must survive:

• redesigns
• mobile apps
• partner integrations
• analytics
• AI
• new features
• new markets

If it doesn’t survive these, it was never a real data model.

4. You over‑aggregate because you’re afraid of making multiple requests

Some developers believe:

“We need one endpoint for the entire page.”

No, you don’t.

Making multiple async calls is:

• cleaner
• more predictable
• easier to cache
• easier to invalidate
• far more flexible

Aggregation is a tool, not a default.

5. You don’t understand entities vs. projections

Entities = the truth of your business
Projections = reshaped, convenient data for a specific use‑case

If you mix them, you get:

• UI fields leaking into persistence
• domain rules encoded inside components
• APIs that break with every design update
• Models nobody understands anymore

Good developers keep these two worlds separate. Great developers document the projection boundaries.

6. You never ask the hard questions

The best data architects ask:

• What is the source of truth?
• What entities actually exist?
• What invariants must never break?
• Would a mobile app use this?
• What happens if the UI changes completely?

If you never ask these questions, you’re not modeling — you’re sketching.

🔥 So… how do you get better?

✔️ 1. Model the domain before the API

If you can’t explain the business with boxes on a whiteboard → don’t write the endpoint.

✔️ 2. Keep entities pure

No UI fields, no layout info, no Figma‑driven naming.
If your database tables look like React components, stop everything and refactor.
If you chose a document database because it mirrors the UI, ask yourself:

“What if there was no UI at all?”

✔️ 3. Prefer multiple granular endpoints

Frontend frameworks are built for composition. Use them. Let the UI combine the data. Don’t let the UI dictate the data.

✔️ 4. Use projections sparingly — and name them clearly

• /orders → entity
• /orders/overview → projection
• /dashboard → projection
• /users/:id/profile-view → projection

Good naming avoids 80 % of confusion.

✔️ 5. Design for multiple frontends

Ask yourself:

• Would this structure still make sense if I built a mobile app?
• If a partner consumed the API?
• If I fed this into an analytics pipeline?
• If I replaced React tomorrow?

If the answer is no, start over.

✔️ 6. Think in relationships and constraints

A real data model is not “objects with stuff inside.” It’s:

• entities
• references
• invariants
• constraints
• timelines
• state machines

This is where a developer becomes an architect.

✔️ 7. Simpler is better

Multiple small, meaningful entities are easier to maintain than one giant “god object.”

✔️ 8. Avoid deep nesting — prefer flat structures

Your API should deliver flat, normalized data. Let the UI handle grouping, filtering, nesting, aggregation. Flat data = predictable data.

✔️ 9. Use correct naming — and be consistent

Clear naming saves lives. UserGroupsResponse is instantly understandable. If your naming forces people to guess → it’s wrong.

✔️ 10. Anticipate change

Your model will grow, evolve, and get more complex. Design with flexibility in mind. Future‑you will thank you.

🎯 Final message

You don’t suck at structuring data because you’re bad. You suck because nobody ever taught you to think beyond the screen.

Once you learn to separate:

• domain vs. projection
• entity vs. layout
• truth vs. convenience

…everything becomes easier. Screens change every week. Good data structures last a decade.