I wrote a simple DTO to transfer data from one point to another, or so was the initial thought.Now I just caught myself in the act of doing various things in the DTO, for simplicity's sake, like converting data in a DTO setter to make sure it fits the format, or even validating it and throwing an exception, to reduce method calls / simplify the point where you are actually hydrating the DTO with information.As DTO's  by the definition I know  should not have any behaviour except storage and retrieval of data, I'm now looking for a better structure.The DTO's used here are mainly for transferring data from one source class (controller) into other classes (e.g. payment gateways) to have the same naming of data (e.g. price for the transaction price) for all gateways, which then are processed accordingly in the anticorruption layer in front of the payment gateway's SDK provided by their vendors.User code --> DTO -> Gateway ACL (-> SDK -> )As my current setup does not really line up with a DTO definition, I'm now looking for an architecture that is clean and matches a design pattern.An example of my now non-DTO-compliant DTO:class GenericDataTransferObject {    protected $price;    public function setPrice($price) {        $this->price = $this->convertAmount($price);    }}abstract class AbstractDataTransferObject {    protected convertAmount($amount) {        //     }}How would this look like in a perfect world?
Converting data in setters in a DTO
dto
You can add a new layer (that I usually call adapters or glue) to handle these conversions between user objects and DTOs.User code --> adapters/glue --> DTOThe adapter code would look something like:class MyAdapter {    public toDTO(BusinessObject $bo) {        DTO $dto = new DTO();        $dto.setPrice(convertAmount($bo.getPrice());        return $dto;    }    private convertAmount($amount) {        //Convert according to some rule    }    public fromDTO(DTO $dto) {        //If the reverse operation is needed    }}