I do this even if the DTO is essentially 1-1 the same as a domain type, because it might not always be the case and I don't want to code myself into an awkward corner in the future. This way, your business logic can deal with the shape of data that is best for the internal code, and your HTTP API has the best shape for consumers of the API.

So, if I'm writing an HTTP API where users can request a specific Foo, or a list of Foos, or whatever, then I'll often have a Foo class and a FooDto class specifically for serialization to an HTTP response body. To elaborate, I try not to keep my public API somewhat segregated from my business logic code, and serialization is not usually part of your business logic. If the out class is a 'domain entity'-to borrow a term from domain-driven design folks-(e.g., if you're Twitter, a Tweet or a User would be domain entities), then it's a trick question because I don't ever mark domain entities as serializable.

If the outer class is a prolific, value-like, general purpose, class (e.g., a DateOfBirth class that has a LocalDate and a ZoneOffset), then I just suck it up and annotate the fields. I handle it two different ways depending on what the containing/outer class is 'for'.

Data class serializable kotlin