Best mapping practices in an enterprise application

Question

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?

Answer 1

The simple answer is 'it depends'.

If your team/organisation doesn't have a settled consensus then you need to agree the approach with them - 'best practice' is less about choosing one approach over the other, but about consensus and consistency of architecture, idioms and design across your team/organisation.

This is a design decision for your team (and probably one of many), so the only people well-placed to decide which way to lean are those who are most familiar with the projects, know the architecture and the day-to-day problems faced by people who work in the code. You won't find any useful answers from strangers who don't know anything about your team or projects.

Neither approaches are uncommon, with many variations in-between. AutoMapper is commonly used to help with layer-separation in .NET, however YAGNI and the risk of overengineering or code bloat due to it drowning in 'boilerplate' are equally common and valid concerns.

A few things to keep in mind when talking to your team:

• Codebase size - coupling and layering within an application can be significant in a traditional giant monolith. Less so in a tiny microservice or cloud lambda.
• How new joiners and junior/inexperienced developers perceive the wider codebase and architecture, and they find easier to reason over and maintain.
• Automated testing, and whether there's much/any impact on unit or integration testing.
• Established practices/ways-of-working and majority preference for the rest of the team.