A previous article mentioned the naming of objects. The core point is: naming should reflect business roles and professionalism to improve the readability, cohesion and extensibility of the code, and ultimately improve maintainability.
Maintainability is the core of the software system.
But understanding this concept may require some background knowledge and time, so how to get started quickly? This article briefly elaborates on these concepts and illustrates the progressive process of naming through a case study.
The difference in naming between core and non-core fields
Object naming first requires distinguishing what we are naming, and whether the object is located in a core domain or a non-Core Domain.
-
-
-
Core AreasIt refers to the key part that carries the essence of the business and directly reflects the core value of the system. For example, in the school management system, the "CourseSchedule" is the core area, responsible for coordinating courses, teachers and classroom resources; in the e-commerce system, the "Order" is the core area, covering the life cycle of commodity purchases. The naming of core areas should be highly close to business terms and reflect professionalism and role responsibilities.
-
Non-core areasIt is a supporting technical module, such as logging (Logging) and data access (DataAccess). These parts can be named with appropriate technical suffixes (such as "Manager" and "Repository") to highlight their support roles.
-
-
Why distinguish? Because the naming of core fields directly affects the clarity of business logic and the maintainability of the system, rather than the core fields pay more attention to the universality of technological implementation. For example, "CourseSchedule" can visually express the business role of course schedules more intuitively than "ScheduleManager", while "LogManager" is suitable for non-core logging functions. If it corresponds to DDD, these two parts are usually divided into core domains and support domains.
Why do core domains need to be closer to business? The core domain is the core competitiveness of the business and requires a high degree of customization and accuracy. Therefore, overly generic naming should be avoided to avoid concealing the uniqueness of the business.
Name as close to the real world as possible
At the beginning, we first distinguished between core areas and non-core areas. The rules we mentioned below are mainly applied and core areas.
For core areas, naming requires more from the real world, because the concepts of the real world have developed and evolved for a long time: roles and domain concepts in the real world, such as "customers", "orders", "bank accounts", "doctors", "patients", etc., are not fabricated out of thin air, but developed through long social practice, business activities, scientific research, etc. They are constantly verified, revised and refined in practice, and their boundaries, responsibilities and functions are often very clear and mature.
At the same time, since objects in the real world are more common, they have already understood the concepts and meanings of these objects in daily life, and no longer need to add additional load to the software (remember to do English reading comprehension when I was in school. If the topic is related to daily life, you can roughly guess the meaning of the article if you don’t recognize many words. If the article is too abstract and the content mentioned is not in daily life, even if you know every word, it is still difficult to understand the concept of the article?)
Below is a simple demo description, a school class schedule system that can extend explicit and implicit responsibilities through reasonable naming.
/**
* Represents the field objects of school teaching arrangements
* The core responsibility is to manage course arrangements and resource coordination
*/
public class CourseSchedule {
// Core responsibilities (explicit)
private Map<TimeSlot, Classroom> assignedRooms;
public void assignTeacher(Course course, Teacher teacher) {
/* Assign teaching teachers and verify qualifications */
}
// Core responsibilities (explicit)
public boolean checkTimeConflict(LocalDateTime newSlot) {
/* Check if the new period conflicts with the existing course */
}
// Undeserved responsibilities:
// 1. Do not handle student attendance (belongs to AttendanceSystem)
// 2. Teacher salary is not calculated (belongs to PayrollSystem)
// 3. No teaching equipment is managed (belongs to TeachingEquipmentResource)
// Implicit responsibilities (subsequent expansion)
public void generateIcalFeed() {
/*
* New requirements: Generate calendar subscription link
* Although not reflected in the class name, the course sheet naturally needs time synchronization function in reality
* Add this method to conform to the natural extension of the object's responsibilities
*/
}
}
Not familiar with the field
Although the CourseSchedule table class above is easy to understand in daily life, it also has certain domain knowledge. What should we do if we are not familiar with the domain at the beginning? For example, "CourseSchedule" involves professional knowledge in school management. As a developer, what should I do?
Start with real roles
Generally speaking, when developing code in a certain field, you can first understand the basic knowledge and vocabulary of the field. Of course, if possible, it is best to communicate with people with experience in this industry, that is, the so-called field experts, such as the example of CourseSchedule, which can extract nouns - key entities (such as "course" and "classroom") and verbs (such as "arrangement" and "conflict inspection") and gradually build naming.
Avoid the lack of soul technical suffix
If you can't think of a name at the beginning, you can first avoid using fuzzy suffixes such as "er" and "or" as much as possible, such as "Scheduler" and "Processor". These naming lack domain semantics and are difficult to reflect business roles, which may lead to lost business accuracy and customization. But except for vocabulary that has become a domain entity itself, such as "Teacher".
Progressive evolution
At the beginning, if you didn’t think of a better name, you can start from simple, learn new fields and gradually evolve as the development progresses. It is still the example of CourseSchedule:
Phase 1 - ClassData (Pure Data Container)
At this stage, naming only focuses on the storage of data and lacks the expression of business semantics. As a pure data container, ClassData is simple and easy to understand, but its limitation is that it does not reflect the business role of course arrangements, only stays at the technical level of data collection, and has a blurred boundary of responsibilities and cannot reflect the logic of the real world.
/**
* Simple course data class
*/
public class ClassData {
private List<String> classes;
private List<String> teachers;
private List<String> rooms;
public void addClass(String className, String teacher, String room) {
/* Simple data addition */
}
}
Phase 2 - ClassSchedule (Introducing business concept)
Compared to ClassData, ClassSchedule took a key step, starting to introduce business concepts, naming shifts from a mere data container to a preliminary expression of course arrangements. The advancement lies in mapping the teacher and classroom allocation relationship through teachersAssignments and roomAssignments, adding simple business logic (such as time availability checks). However, its limitations are still obvious: naming is still technical, and it is not completely close to the real world's "course schedule" concept, the definition of responsibilities is relatively shallow, and lacks in-depth reflection of the rules of the field.
/**
* Course Schedule
*/
public class ClassSchedule {
private Map<String, String> teacherAssignments; // Teacher Assignments
private Map<String, String> roomAssignments; // Classroom allocation
public void assignClass(String time, String teacher, String room) {
/* Basic course arrangement logic */
}
public boolean isTimeAvailable(String time) {
/* Simple time check */
}
}
Stage 3 -CourseScheduleManager(Domain responsibilities have begun to take shape)
Compared with ClassSchedule, CourseScheduleManager goes further in business expression. By introducing fields such as Course and Teacher, naming begins to be close to the realistic logic of school management. Progress is reflected in the refinement of responsibilities, such as teacher allocations have added business rules, and time conflict inspections are more specific, reflecting the deepening of domain knowledge. However, its limitation is that the "Manager" suffix still has a technical color and fails to completely get rid of the meaning of abstract management, which may blur the intuitiveness of the "course sheet" as a core business role and limit the semantic accuracy of naming.
/**
* Course Schedule Management
*/
public class CourseScheduleManager {
private Map<TimeSlot, Classroom> roomAssignments;
private Map<Course, Teacher> teacherAssignments;
public void assignTeacher(Course course, Teacher teacher) {
/* Added business rules for teacher allocation */
}
public boolean checkScheduleConflict(TimeSlot slot) {
/* Added time conflict check */
}
}Final stage - CourseSchedule (full domain object)
Compared with CourseScheduleManager, CourseSchedule has completed the transformation from a technical perspective to a domain perspective, which is completely close to the concept of "course schedule" in the real world. The improvement lies in removing the "Manager" suffix, directly named after the business role, and clearer responsibilities. Methods such as generatedIcalFeed naturally extend the time attributes of the course sheet, showing scalability. At this time, there are no obvious limitations, and the naming is highly consistent with the essence of the business, which is intuitive and professional.
/**
* Represents the field objects of school teaching arrangements
* The core responsibility is to manage course arrangements and resource coordination
*/
public class CourseSchedule {
private Map<TimeSlot, Classroom> assignedRooms;
public void assignTeacher(Course course, Teacher teacher) {
/* Assign teaching teachers and verify qualifications */
}
public boolean checkTimeConflict(LocalDateTime newSlot) {
/* Check if the new period conflicts with the existing course */
}
public void generateIcalFeed() {
/* Generate calendar subscription link */
}
}
summary
Naming is a seemingly small but crucial link in software design. Naming is not only a simple code issue, but also a presentation of our understanding of the nature of the business, but also the key to communication between business logic and field experts. By distinguishing between core areas and non-core areas, we have made it clear that naming should prioritize serving the essence of the business, especially in core areas. Concepts close to the real world can bring about semantic clarity, clear responsibilities and improved maintainability.