NGHỆ THUẬT ĐẶT TÊN THEO DOMAIN-DRIVEN DESIGN (DDD): KHI CODE KỂ CÂU CHUYỆN KINH DOANH

1. Sai Lầm Kinh Điển: Khi Lập Trình Viên Tự Sáng Tạo Ra Ngôn Ngữ

Hãy nhìn vào một đoạn code CRUD truyền thống thường thấy trong các dự án Backend:

PHP

// Code mang tư duy kỹ thuật (Technical-centric)
class OrderManager {
    public function updateData($id, $statusFlag) {
        $row = DB::table('tbl_orders')->where('id', $id)->first();
        if ($row->status == 1) {
            DB::table('tbl_orders')->where('id', $id)->update(['status' => 2]);
            // Gửi email thông báo
        }
    }
}

Nếu một người quản lý nghiệp vụ (Business Analyst) hoặc giám đốc kinh doanh đọc đoạn code trên, họ sẽ phải nheo mày hỏi: "Trạng thái 1 là gì? Trạng thái 2 là gì? Tại sao gọi là updateData mà không phải là tiến hành xác nhận đơn hàng?".

Đó là sự đứt gãy kinh điển giữa Business Domain (Nghiệp vụ thực tế) và Technical Implementation (Cách lập trình viên viết code). DDD sinh ra để hàn gắn khoảng cách này.

2. Ngôn Ngữ Chung (Ubiquitous Language) - Trái Tim Của DDD

Nguyên tắc cốt lõi đầu tiên và quan trọng nhất của DDD trong việc đặt tên là Ubiquitous Language (Ngôn ngữ đồng điệu).

Quy luật vàng ở đây là: Người kinh doanh gọi nó là gì, cơ sở dữ liệu lưu nó là gì, thì trong Code (Class, Method, Variable) phải gọi chính xác bằng cái tên đó. Không được tự ý dịch nghĩa, không được viết tắt lém lỉnh, không dùng tiếng lóng kỹ thuật.

• Nếu nghiệp vụ gọi khách hàng nợ tiền là OverdueAccount, đừng đặt tên biến là bad_user_v2.

• Nếu nghiệp vụ là "Hủy đơn hàng do khách đổi ý", phương thức phải là cancelDueToCustomerChangeOfMind() thay vì setStatusToThree().

3. Phân Cấp Các Thành Phần Theo Thuật Ngữ Domain

Khi áp dụng DDD, tên của các Class và Method sẽ bộc lộ ngay lập tức vai trò của chúng trong mô hình kiến trúc:

• Entities (Thực thể): Có định danh duy nhất và thay đổi trạng thái theo thời gian.

  • Cách đặt tên: Danh từ đơn, mang tính nhận diện cao. (Ví dụ: Order, Customer, Invoice).

• Value Objects (Đối tượng giá trị): Không có định danh, được định nghĩa hoàn toàn dựa trên tập giá trị của nó và có tính bất biến (Immutable).

  • Cách đặt tên: Mô tả chính xác bản chất giá trị. (Ví dụ: Money, Address, EmailAddress, Latitude).

• Aggregates & Aggregate Roots (Cụm thực thể gốc): Nhóm các đối tượng liên quan với nhau được quản lý qua một gốc rễ chung để đảm bảo tính toàn vẹn dữ liệu.

  • Cách đặt tên: Gốc rễ sẽ đại diện cho cả cụm. (Ví dụ: Order là Aggregate Root quản lý các OrderItem).

• Domain Services (Dịch vụ nghiệp vụ): Chứa các logic nghiệp vụ không thuộc về riêng một thực thể nào.

  • Cách đặt tên: Kết hợp danh từ và động từ hành động nghiệp vụ rõ ràng. (Ví dụ: OrderMatchingService, FeeCalculationService).

• Repositories & Factories:

  • Repositories: Chuyên phụ trách việc lưu trữ và truy vấn thực thể. Tên chuẩn: OrderRepository, UserRepository.

  • Factories: Chuyên khởi tạo các đối tượng phức tạp. Tên chuẩn: OrderFactory.

4. Bí Kíp Đặt Tên Method: Động Từ Phản Ánh Hành Vi Nghiệp Vụ

Trong lập trình hướng đối tượng thông thường, chúng ta hay lạm dụng các từ chung chung như save(), update(), process(). Trong DDD, tên của một Method phải kể một câu chuyện về Hành vi (Behavior):

• Tránh xa các Setter lộ thiên: Thay vì viết setUserStatus('active') (nghe rất mang tính cơ sở dữ liệu), hãy viết biểu đạt hành động nghiệp vụ như activateUser() hoặc suspendAccount().

• Sử dụng danh từ cho Factory Method: Khi tạo mới một đối tượng từ các dữ liệu thô, hãy dùng các tiền tố như fromRequest(), createFromDto().

💡 Lời Kết

Đặt tên chuẩn theo Domain-Driven Design không chỉ là việc chọn từ tiếng Anh sao cho hay. Đó là quá trình chuyển hóa tư duy từ "Tôi đang code cái bảng gì trong Database?" sang "Tôi đang giải quyết bài toán gì cho doanh nghiệp?".

Khi code sử dụng đúng ngôn ngữ của nghiệp vụ, những lỗi logic do hiểu sai ý khách hàng sẽ biến mất, và quan trọng nhất: Bất kỳ lập trình viên nào gia nhập dự án vào 2 năm sau cũng có thể đọc hiểu toàn bộ hệ thống như đang đọc một cuốn tiểu thuyết kinh doanh mạch lạc.