> I am tempted to merge it with the HTTP model as well, add JSON tags to it.

If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email.

Second argument: I usually create a simple struct for each method. For example I do not want, that they provide the id for post requests. I want to send the id on get requests so that they can send an update request with the id. I prefer only "non-null" arguments and as a bonus you get a clean (auto-generated) api documentation.

> in the domain model you have a user with email but do not want to expose the email.

You can usually configure that out with @JsonIgnore or something like that. Although this works only for this particular (very simple) example and won't help with e.g. flattening multiple nested objects.

At this point you already have 2 "models", in the sense of 2 "concepts" or 2 "types": the one with the field and the one without. The second one is implicitly defined with these annotations, which has a good chance to be annoying sooner or later when you need it to be explicit.

>If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email.

Another possible problem: having to support two versions of the API at the same time.

All you need is a little conversion function which takes a domain struct and converts it to a DB struct with tags (for example)? Unless it's a very complex entity multiple levels deep, I usually don't find it all that painful. What is it about DTO conversions that makes it painful for you? Being boilerplate, it's probably not very aesthetically looking, but it usually doesn't take more than a minute to write the conversion function.