I've found myself thinking a lot about a good naming strategy or naming convention for website projects that works with data in several different formats. Before I start to outline my current ideas (might change over time) I would like to set the stage for the project.
Let's say we have a website project with the all of these "features":
- A rich domain model with domain entities
- A database to store state of the domain model including repositories
- A MVC front end
- A web api aimed for the front end website (not 3rd party integrations)
- A public web api for 3rd party integration's
Now comes the challenge, all of these different touch points/end points into the system often needs to represent the same thing/entity. We've been taught that for one should not use the domain entity as view model in a MVC-view, we should have a dedicated type that acts as the view model, the problem is that each of these end points probably needs a dedicated type which presents us with a problem that I've had a really hard time to find a perfect solution for:
How should we name all these dedicated types/classes?
First of all, these special representations of the core rich domain model entities are all DTOs (data transfer objects) but since we probably need these DTOs to look different depending on the context we need to name them in a smart and understandable way. The goal would be that a developer should be able to understand what "type of DTO" the code is working with by looking at the type name.
So let's start with some ideas and let's say that the core domain model that we're working here is type called Car.
MVC-view model
This one is quite simple, a very common practice is to suffix the core entity with ViewModel.
Idea: CarViewModel.
Database mapping DTO
In most of my solutions I use a repository that will take in the domain model and store it's state, the repository also returns instances of domain entities. During this process we need to map the domain entity to a model that is suitable for the storage we're using. Let's say a database. So most of the time I would represent the database table as a DTO.
Idea: CarDto
Model for website frontend APIs
Here we're talking about features on the website that make async javascript requests to the backend, something like a filter, a search feature, auto suggest or what ever. These are "ApiModel" but they are used in a context where they've probably will end up as some kind of "view model" when they are rendered into the website. I'm quite sure that this kind of model is different from the model used in public APIs for 3rd parties, so I would like to use a naming convention for them that makes it clear that they are used only for the website.
Idea: CarFrontendModel
Model for public API for 3rd parties
Here we're talking about model types for a external public web api if we're implementing a API that is restful these models could be called a Resource or a ApiModel. I like the idea of calling the "Resource" since a restful api could/shuld have navigation-properties etc. So in this case the "CarResource" might have links to a BrandResource or a "DealerResource". I'm very hesitant about this one but one has to come up with something.
Idea: CarResource
I had two main purposes of writing this blog post, first one is to document and share my ideas and the second is to get input and/or feedback. If you feel that you have other thoughts around this, please share in the comments!
Note: I might (and almost hope) that I'll change my conclusions above based on more experience and feedback.