Objects may be in the same conceptual layer...without being grouped into the same conceptual object.

For example, in a mobile app I may have networking object that knows how to fetch authenticated request from an API.

I next may have an accounts fetcher that uses the network layer to, well fetch account models. And that, in turn, may be used by an accounts repository that manages fetched accounts for the entire app.

And then we have a view model that uses the shared repo, and a view that depends on the view model.

Each layer has a specific role to play. Each layer knows how to talk to the underlying layer, but no deeper than that. And no layer knows about any layer above it.

Now, I may do the same exact set of things in order to manage and display a list of transactions. Which means having a transactions fetcher that's different from the accounts fetcher. And, of course, a transactions VM and view.

Now, per your example, what if I need to add a new field to my transactions view? Well, I'll probably need to change the transaction model and the transaction view.

VM probably won't need to change. A data object is a data object. Repo probably won't need to change.

Now maybe the transactions fetcher requires a change, telling the API we need the additional field... but that only affects that entity, and none of the other "fetchers" in the same conceptual layer.

And all of this is just a long winded way of saying that it all depends on how your application and its layers are structured.