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.

Note

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.

Tip

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

Hil.Shop.Common
Hil.Shop.DataLayer
Hil.Shop.DomainEntities
Hil.Shop.Models
Hil.Shop.ExternalService
Hil.Shop.ExternalServiceProvider
Hil.Shop.InMemoryService
Hil.Shop.Logger
Hil.Shop.Service
Hil.Shop.ServiceInfrastructure
Hil.Shop.FileServer
Hil.Shop.Tests
Hil.Shop.ValidationService
Hil.Shop.WebApi

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

Tip

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:
PesronInsertVm


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

Tip

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

English
Persian

Naming Pattern in youtube More videos

Infrastructure .NetCore | Asp.net Infrastructure Template C# | Clean Architecture Net Core Examplerefactor Inf | Clean Architecture .Net Core | asp.net core architecture best practices | asp.net core clean architecture github | asp.net onion architecture | asp.net core mvc clean architecture github | asp-net-core layered architecture github | n-tier architecture net core 3.1 web api | asp.net core onion architecture github | asp-net-core architecture best practices github | clean architecture github | clean architecture example | clean architecture design pattern | clean architecture onion asp.net | Domain-Driven Design in ASP.NET Core applications | Onion Architecture In ASP.NET Core With CQRS | Designing a DDD-oriented microservice | net domain-driven design with c# source code | domain-driven design project structure | how to implement domain-driven design .net core | hands-on domain-driven design with .net core pdf github | domain-driven design template | domain-driven design microservices example | domain driven design example c# asp.net | refactoring infrastructure net core | clean architecture net-core github