Naming convention of model classes in clean architecture presentation, domain, and data modules

Question

I have presentation, domain, and data modules. I am fetching football player information from a sports api. I use a mapper class to map the data class between the module layers

I am just wondering what is the convention when naming the data class in different module

In my data layer I will be fetching the player from the api and saving it locally.

Data Layer
local:
    PlayerTable
    
repository:
    PlayerEntity
        
Domain Layer
    PlayerModel
    
Presentation
    Player

I have just postfixed the Table, Entity and Model. And for Presentation Player is what it is.

Just wondering is there any particular convention. I have seen didn't styles to this, but the main thing is to keep it consistent.

Just wondering what other dev's do for naming their data classes.

Thanks for any suggestions,

Answer 1

There is no official naming scheme on how to name your classes. But in most languages:

• Class names should start with an uppercase
• Variable names should start with a lowercase
• Constants should be all UPPERCASE_WITH_UNDERSCORES

Some developers are prefixing their variables like this:

• mVariable for public member variables of a class
• _variable for private variables of a class
• _variable for backing fields within a class
• sVariable for singleton fields

Personally I don't use these prefixes, because I think they are a relict from times before we had syntax highlighting. Today our IDEs color everything so it is easy to distinguish between class names, variable names and so on.

In the end it is up to you how to organize your code and with every project you will change it and improve it a little bit. Sometimes you will work in a team that has a fixed code guideline. Sometimes such a code guideline is even enforced by Lint rules.

Think about it in one of these ways:

• In two years while never looking at this code: Will you be able to tell what the class is responsible for by just reading its name?

• Make the class name as short as possible, but as explicit as neccessary. E.g. If a class is already in a package named model, you don't need to name it PlayerModel. Player should in most cases be enough then.

• Your code is a love letter to your future self. If you read it in a few years, you will either love yourself or hate yourself (more often the latter..)

• Will another developer who has no clue what your class does understand what it is responsible for.

Also very important:

NEVER be afraid of refactoring! If you realize that a name is shit, then rename it.

Also a good hint:

Read a few books on clean code. I can recommend "The pragmatic programmer" and of course the infamous "Clean Code".

I hope this gives you a bit of guidance on this topic! Have fun coding :)

UPDATE:

If you encounter the situation that you are using two classes with the same name in 1 file, most languages provide "import aliases". For example in Java, you can then type in the import statement

import some.file.from.network.Player as NetworkPlayer
import model.class.from.my.app as AppPlayer

You can then reference the 2 different classes in your file with the aliases AppPlayer and NetworkPlayer to make it clear and easy to understand which is which.

Answer 2

The way I see it, Clean Architecture is a philosophy on how to design systems in a way that is easy to read, obvious to understand, and with specifically divided responsibilities.

If we follow that philosophy, some of those models/classes/instances should never cross paths. This means that the DataBaseModel will not exist in the same context(java file, python modules, etc...) as the PresentationModel. For this reason, is fairly common to see people implementing this with the most obvious names and make the context be the classifier.

For instance, if you have a data model representing a player, the obvious name to give the class handling it is Player and having a namespace(or package) reflecting the database handling nature, like database.Player or database.models.Player. The same goes to the presentation layer.

Concerning entities, I follow exactly the same rule. I always have a namespace core(my personal preference) where I store all the code of the entities and usecases. This core namespace can have other sub-namespaces and no third party code is imported(or keep a minimal set of dependencies). In this context, if I need an entity to represent a player I will call it Player. The interfaces required for the external layers to communicate with the core are defined here and depend only on the entities.

The only situation were the external layers can communicate with the entities code is when implementing the core interfaces. There, I actually follow @muetzenflo sugestion and give an alias to my entities on import or use the namespace(entities.Player).

I'm not sure that a really convention exist and I'm not sure that one is really required. The ultimate goal is to make the code easy to understand, easy to maintain and easy to develop on. If we have justification to scrap some of this guidelines in order to make better, more reliable and easier to read and to maintain, so be it.