The author made this story available to Medium members only.

Please either update the post with the URL that gets around this login-wall; or, remove the post because the article is not on the public web.

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.

Yeah, this should be common software engineering problem for a senior engineer

In the beginning, there is only one data model used both externally and internally, to keep things simple. Now that they’re diverging, it’s time to draw an abstraction boundary that translates between internal and external models.

I’m not super strong with Java, but subclassing to handle v1/v2/vX doesn’t sound like the right thing to do. I’d detach the old model from the API while otherwise keeping it unchanged, implement a new pathway to connect with the new API, then translate in/out of the old model before it passes into the existing system. This way, the surface area of change and of integration is isolated and decoupled from everything else.