This question might seem like a trivial question. But here it goes.
Currently, I'm working with this .NET Core application, an N-tier application consisting of a Vue frontend, business logic layer, and a service layer. It's a medium-sized application with + 50 endpoints that the frontend connects to. From the service layer, multiple internal applications and databases are called.
So let's say our application is sending post requests from the frontend, and this Request should eventually reach a REST API in another backend application.
Then the simplified flow is like this: The frontend sends request -> model is mapped to C# DTO in the controller -> DTO is mapped to another DTO which is sent into the Service layer (this DTO is what the endpoint in the other application expects) -> Request is sent to other application.
So normally, we have separate integrations DTO's and other DTOs used to communicate between frontend/backend.
Other times data is retrieved from another application and then mapped to DTO, which is sent to the frontend eventually.
Her it's like: Response from other applications mapped to another DTO, which I sent to the frontend.
I have been asked by various colleagues why not share DTO - often, it's one-to-one the same data type and name in both DTO. My autopilot answer has long been, yes, more code needs to be written - but not reusing DTO's is easier to manage, more decoupled, easier to refactor, etc.
But lately, I have had a doubt whether or not my answer is common/best practice in general.
So what is your take on this?