In the EmailContacts example, the properties of a Contact are listed in the Contact class and in the CreateContact class. (there is no UpdateContact class, which a real world app would also need)
Is it normal practice to list all of the properties in 2 or 3 different classes? Seems like this would be difficult to maintain and bad practice if the Class has 50 properties.
I'd first check out ServiceStack Backgrounds concepts for more info, specifically Why Remote Services should use DTOs which states that DTO properties declaratively state the intent of each Type, i.e. they shouldn't be thought of as duplicated logic you want to hide behind DRY methods. It also includes built-in auto mapping examples showing how you can easily map between different types.
These are different types for different purposes, e.g. the Operation Types CreateContact, UpdateContact define the inputs for each operation whilst Contact defines the data model, it's typical for each of these different Types differ as to what schema is allowed when an entity is first created vs updated vs what's persisted in the Data Model.
You're free to share a base class of common properties if preferred, however when the each of the definitions of these different types diverge you could be introducing breaking changes when splitting them out into discrete classes as the implementation progresses.
For a larger real-world ServiceStack Example you can check out the code-base for https://techstacks.io available on GitHub at https://github.com/NetCoreApps/TechStacks
