[counttheforks]

In webapps it's often very useful to accept a subset of a domain entity as an APIs request body, or to return it as a response body.

It's nice having separate classes to describe the request & response bodies because this lets you automatically generate OpenAPI descriptors which can then be used for client generation and so on.

When your domain objects are small it's easy to just manually copy the data between your domain entities and request & response objects. Once your objects grow it's convenient to just automate the mapping in a way that still gives you compile-time correctness checks.

[hateful]

Agreed. If you've come along the journey of first using the json attributes on your Domain objects to try and define your return but then get stuck the first time you have another API call returning a different subset of fields.

It all clicked for me when I read somewhere: "The best way to define a data structure is a class, that's what they are".

So now you can create Response and Request versions of your classes and use AutoMapper to convert them.

When someone green comes into my Domain Driven project they always have the same question - why are there so many versions of your classes? In my project I have the aforementioned versions of those classes, but also the auto-generated Entity Framework classes in the Repository - which mimic the database structure - but it's not 1:1 (e.g. a many to many relationship will most likely not have a Domain model for the joining table - unless it has its own non-Foreign Key fields defining that relationship). But I don't use AutoMapper for that part - just a lot of code - maybe one day.

Oh, and then I have at least one more version in Typescript!

[grandpoobah]

All those KLOCs! Such productivity!