Naming Pattern & Conventions
Consistent Naming for Readability, Durability, and Clear Architecture
Every company or project should have its own naming pattern to help us easily understand previous concepts and add new ones. Good and consistent naming creates a great flow, increasing code readability and durability.
An important feature of a good framework is having a strict naming pattern that all programmers follow across folders, files, classes, functions, and variables. If any file is separated from the project, developers should be able to specify its exact address purely from its file name.
1. Controller Action & ViewModel Pattern
In AUA Framework architecture, incoming client HTTP payload data for creation or updates must be passed to controller actions using dedicated ViewModel (Vm) classes.
[ApiController]
[Route("api/[controller]")]
public class PersonController : BaseApiController
{
[HttpPost]
public async Task<IActionResult> Insert([FromBody] PersonInsertVm personInsertVm)
{
// Business execution logic processed via service layer
return SuccessResult();
}
}2. Data Model (Dm) Refactoring Pattern
When a service method requires multiple parameters, AUA standards dictate encapsulating arguments into a DataModel (Dm) object to prevent long parameter lists and improve code maintainability.
// ❌ Anti-Pattern: Long parameter signature
public void ChangeStatusPerson(
long personId,
bool isActive,
EUserLevel userLevel)
{
// Service logic
}// ✅ Encapsulated parameter object using Dm
public void ChangeStatusPerson(
ChangeStatusPersonDm changeStatusPersonDm)
{
// Service logic
}public class ChangeStatusPersonDm
{
public long PersonId { get; set; }
public bool IsActive { get; set; }
public EUserLevel UserLevel { get; set; }
}"You should name a variable with the same care we do in naming a first-born child."— Uncle Bob (Clean Code)
Layer Naming Formula
In the AUA framework, the standard structure for layer naming follows this exact pattern:
Company Name (3-4 chars) + Project Name + Layer Name
* Note: The number of layers can vary depending on each business requirement.
Example: ATS Store Layers
Here is how Ats applies the naming pattern for its store project layers:
Component & Suffix Conventions
Person & PersonDto
Use DTOs at the input and output of APIs instead of exposing raw Entities. Each entity should have at least one DTO since services are designed to take entities/DTOs cleanly during creation.
PersonVm & PesronInsertVm
AUA uses the Vm suffix. If multiple view models are needed for an action, combine ControllerName + ActionName + Vm. Always try to use common view models for APIs when possible.
FunctionName + Dm
When function or service parameters exceed 2, wrap them in a Data Model object using the Dm suffix. Data Models have nothing to do with entities/APIs and are only used internally between functions to prevent long parameter lists.
"If you think good architecture is expensive, try bad architecture."AUA Framework Philosophy