Balancing separation of concerns, implementation hiding and data transfer objects

Implementation hiding demands us to hide the internal structure of a class from the user. Let's state for the sake of simplicity: reduce the number of getters/setters to a minimum.

Separation of concerns demands that there should be only one reason for a class to change. Thus, one must not let a class of the service layer do service layer things and save data to the data storage, for instance.

Data transfer objects (DTO) are used to transport data from the service layer to the data access layer.

In order to build a DTO, I need to, in the worst case, read all members of the service layer class. This would require a maximum number of getters, which violates implementation hiding.

Deriving classes which should be transformed to DTOs from a common Storable abstract base class with a virtual method Dto buildDto() would violate separation of concerns.

Can you recommend strategies coping with this? Or is there actually a common practice in this regard?