When it comes to Microservices, we often forget one important characteristic of the architecture. Services' SDLCs are (or should be) independent too.*.
Different SLDC and different dev teams
We should bear in mind that there could be more teams involved in the development of the MS ecosystem, each of which in charges of one or more services. In turn, they might be located in different offices, cities, countries, plan... Perhaps, they don't even know each other, making very hard for them to share knowledge or code. That could be very convient because shared coud also implies a sort of sharing reasoning and something important to recall is that, whatever makes sense for a specific team, doesn't has to make It for another team necessarily. For instance, the DTO's data structure could be convenient for one team (service) and not to be for others.
Different needs, different technologies
Isolated SLDC' also allows teams to choose the stack that best suits their needs. Imposing DTOs implemented in a specific technology limits the capacity of the teams for choosing the adequate tools and stacks.
DTOs are neither business rules nor services contracts
On the other hand. What are DTOs? Plain objects with no other goal than moving data from one side to another. Bags of getters and setters. It's not the kind of "knowledge" that worth reuse, overall because there's no knowledge at all and these are components prone to change with all that it means.
Contrary to what Dherik has stated, it must be possible for a service to change its DTOs without having to make other services to change at the same time. Services should be tolerant readers, tolerant writers and fail tolerant. Otherwise they cause coupling in such a way that makes the service architecture a no sense.
Different business, different interpretations
While there could be (and there will be) cross-cutting concepts among services, it does not mean we have to impose a canonical model to force all services to interpret them in the same way. Recall what I said about the DTOs data structures.
Say our company has three departments, Customer Service, Sales and Shipping. Say each of these releases one or more services.
Customer Service, due to its domain language, implements services around the concept of customers, where customers are persons. For instance, customers are modeled as name, last name, age, gender, email, phone, etc.
Now say, Sales and Shipping model their services according to their respective domain languages as well. In these languages, the concept customer appears too but with a subtle difference. To them, customers are not (necessarily) persons. For Sales, customers are a Document number a Credit Card and a billing address, for Shipping a full name and a shipping address too.
If we force Sales and Shipping to adopt the canonical data model of Customer Service, we are forcing them to deal with unnecessary data that could end up introducing unnecessary complexity if they have to maintain the whole representation and keep the customer data in sync with customer service.
* Here is where the strengths of this architecture lays on