I have a composite Dto, where properties are primitive values or other Dtos (that occurred in many places).
Eg :
In this example AddressDto and ContactDto are used in many other Dtos (not only PersonDto), so i am tempted to add some business logic to those Dtos. In particular i would like to add update logic to those Dtos (eg: define an IUpdateable interface) to handle how the Dtos persist information.
In that way when i have to deal with a Dto i can check if it's a composite one, and in the case i know i can rely over IUpdateable children Dto contained in the parent Dto to get the "right update logic".
But i have the feeling this is not the correct way to proceede, Dtos (as name imply) shuld carry only information and no business logic. I don't like the idea to start attach logic to Dto also because then i am constrained to that specific logic (if i need a ContactDto with that exact structure but different update logic, my only option is to derive a new type..and this seems ugly)
That said, so far, i have indulged, in use interfaces over Dtos only if the interface is merely a "tag" that describe the "scope" of the Dto; and in that sense guarantee the fact that Dto will contain some properties with a specific meaning.
But now it's not clear to me how to achieve two goals :
Optionally i would like to achieve the goals above in the simplest way without too complex artchitecture
But i have the feeling this is not the correct way to proceede, Dtos (as name imply) shuld carry only information and no business logic
yeah, you are absolutely right.
In particular i would like to add update logic to those Dtos
Logic should be placed in services if you use service layer architecture. Ultimately, in any architecture you choose, there is going to be some component or layer that has most of the business logic. Read this beautiful answer about where your logic should be placed.