Experienced Devs

One thing that is often overlooked in enthusiastic architecture is lines of concern. If you have two APIs, you have two data models. They might be the same today, but they will diverge eventually. A customer in the AR system is different from a customer in the CRM system.

But also, an API is an API. As long as it is a serializes and deserializes on both ends, you are implementing the contract. In this case, author just made their own class, but nonsensically and uselessly tied it to something different. Just ignore the [non-]standard model and create your own DTO. Because in the end if the model is updated and the contract is changed, you aren't going to be following it anyway until you (painfully) update your own.

That said, I understand business often imposes wrong-headed requirements because the wrong people are making the decisions. If there was a hard requirement to use the standard data model, the author failed in any event.

On the other hand, it kinda reads like the DTO is being used within the business logic instead of having a data model separate from the DTO. Don't do that. You have a request model, a response model, a business object, and then often either a persistence model (entity) or upstream service request and response models. Lots of times those can be identical but I've seen a lot of code where tying the entity to a response model creates a hell of a lot of headaches down the road.

By using different classes, you allow them to diverge naturally and only need to update the mapping layer. Don't do that shit because the longer it goes on the more painful it is to separate later.