Naming Pattern

Every company or project should have its own naming pattern to help us easily understand the previous concepts and add new concepts to the project. Good and consistent naming creates a good flow in your project, thereby increasing code readability and durability. An important feature of a good framework is having a good naming pattern, which all programmers should follow. In this framework, all components are named, such as: folder, file, class, function, variable, etc.

"You should name a variable with the same care we do in naming a first-born child" (Uncle Bob in Clean Code).
Each team must use a specific naming pattern, such that if any file is separated from the project, all programmers can specify the exact address of the file from the file name. For the AUA framework, we have suggested the following naming pattern.


The layer naming that the AUA is representing is as follow: Company Name + Project Name + Layer Name

Naming Layers

The company name should be 3 or 4 characters short for the company name.


For example, Heilton uses the following naming pattern for its store project for its layers:


However, the number of layers can vary depending on each business.


For example, for the entity of Person, we do naming in this way:

Entity: Person
Data Transfer Object(DTO): PersonDto

We can use DTO at the input and output of Api and use DTO instead of sending and receiving to Entity . DTO can be considered larger and equal to Entity. Web Api output and input use DTO instead of Entity. We must have at least one DTO for each entity because the services are designed to take an entity as input when creating an entity.

View Model: PersonVm

For view models, AUA uses the acronym view model, or VM . Of course, if more than one view model is required for an entity, the following combination can be used: ControllerName + ActionName + Vm. For example, for the following control and action, this name is suggested:

public  Class  PersonController
    public  IActionResult  Insert (PerosnInsertVm perosnInsertVm)
        // TODO:


Keep in mind that you should always try to use common views for APIs . If you could not get common input, be sure to create a separate ViewModel. In most cases, DTO can usually be used for all CRUD operations and there is no need to build a View Model.

Data Model: PersonDm

When the parameters of services or functions are more than 2, it is better to put it in a model object, Because the parameters of a function are certainly related and follow a concept, it deserves to be given a name.
Data Model has nothing to do with entities and APIs, it is only used to pass parameters internally between functions and services. We use DataModel in order to prevent an increase in the number of input and output parameters in functions and services, and use the abbreviation Dm to prevent the lengthening of class names. FunctionName + Dm .
For example, in the function below, there are three parameters as input:

public  void  ChangeStatusPerson (int PerosnId, bool IsActive, EUserLevel UserLevel,...)
    // TODO:

Instead of those inputs, we should use a Data Model as follow:

public  class  ChangeStatusPersonDm
    public  int  PerosnId  { get;   set; }
    public  bool  PerosnActiveStatus  { get;   set; }
    public  EUserLevel  UserLevel  { get;   set; }

So, it's time to use that Data Model

public  void  ChangeStatusPerson (ChangeStatusPersonDm   changeStatusPersonDm)
    // TODO:

For Enum, we use the letter E at the beginning of its name. Naming patterns in AUA are visible for each section. Accounting module is fully available. The programmer can name new objects appropriate to that pattern by viewing the naming in the previous sections.

Sample Name Pattern
Entity Person
Entity Config PersonConfig
Data Transfer Object PersonDto
View Model PersonVm
Data Model PersonDm

Naming Pattern in youtube More videos

Naming Pattern in youtube More videos