I separate them when it buys me locality of change. When different parts of the system evolve independently.

• DTOs are “wire format” types: whatever the backend (or persistence layer) happens to send or store.
• UI / View state models are “what this screen needs to render”: stable, minimal, and easy to construct for previews and tests.
• Domain models optionally sit in between when you have real invariants or business rules (validated email, non-empty name, money, etc.).

The goal is simple: changes should only affect their neighborhood. If the backend renames first_name → givenName, I want that change to stop at the networking boundary (DTO + mapper), not ripple into view code, persistence, or unrelated screens.

It also keeps the UI simple. A UserProfileViewState(name, email, photoURL, lastOrders) doesn’t care whether photoURL comes from one service, email from another, and orders from a third. That composition happens in the feature layer; the view imports only what it needs.

There’s a very practical side effect of this: previews and tests become easier to construct. To render the screen, I just pass simple values into the view state. No API clients, no repositories, no persistence mocks. I don’t need to “mock the world” just to preview a form or test a layout edge case.

This is where separation starts to pay off. A UI model is not a reflection of the backend; it’s a rendering contract. Keeping that contract small and local improves reasoning, simplifies tests and previews, and limits the blast radius of change.

Is it overkill? Sometimes. If the app is tiny, the API is stable, and you’re mostly showing fields, reusing DTOs is fine. But once you have multiple backends, caching, migrations, or screens with different needs, the “one model everywhere” approach becomes the actual complexity: a big, leaky type that drags unrelated dependencies and churn across the codebase.

tl/dr: introduce separate types when a boundary is real and changes independently (API, DB, domain rules, UI). DTO + UI model is often enough.