Xử Lý Logic Nghiệp Vụ Phức Tạp

1. Lịch Sử Hình Thành (History)

Cũng giống như Transaction Script và Active Record, mẫu hình Domain Model lần đầu tiên được Martin Fowler đúc kết và đặt tên trong cuốn sách danh tiếng Patterns of Enterprise Application Architecture (2002). Trong phần kết luận của chương viết về mẫu hình này, Fowler đã đưa ra một lời giới thiệu mang tính lịch sử: "Eric Evans hiện đang viết một cuốn sách chuyên sâu về việc xây dựng các Domain Models."

Cuốn sách được dẫn chiếu đó chính là tác phẩm kinh điển đặt nền móng cho cả một trường phái kiến trúc: Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) của Eric Evans.

Trong kiệt tác của mình, Evans đã giới thiệu một hệ thống các mẫu hình tinh hoa nhằm gắn kết chặt chẽ mã nguồn với mô hình cốt lõi của miền nghiệp vụ: Aggregate (Tập hợp kết hợp), Value Object (Đối tượng giá trị), Domain Event (Sự kiện miền), Domain Service (Dịch vụ miền), Repository (Kho lưu trữ) và nhiều khái niệm khác. Những mẫu hình này tiếp nối một cách hoàn hảo nơi Martin Fowler dừng lại, tạo thành một bộ công cụ vô cùng sắc bén để hiện thực hóa mẫu hình Domain Model.

2. Mẫu Mô Hình Miền (Domain Model Pattern)

Mẫu Domain Model được sinh ra để đối phó với những miền nghiệp vụ có logic cực kỳ phức tạp. Ở đây, thay vì chỉ có các thao tác CRUD thêm-sửa-xóa đơn giản, chúng ta phải đối mặt với:

• Các chuỗi chuyển đổi trạng thái chằng chịt, phụ thuộc lẫn nhau (complicated state transitions).
• Các quy tắc nghiệp vụ khắt khe (business rules).
• Các Luật Bất Biến (Invariants): Những quy tắc và ràng buộc nghiệp vụ bắt buộc phải luôn luôn được bảo vệ toàn vẹn ở mọi thời điểm, trong mọi hoàn cảnh!

2.1. Tình huống thực tế: Vòng đời vé hỗ trợ Help Desk

Hãy tưởng tượng chúng ta đang xây dựng một hệ thống bàn hỗ trợ khách hàng (Help Desk). Dưới đây là một đoạn trích từ tài liệu yêu cầu nghiệp vụ mô tả vòng đời của một phiếu hỗ trợ (Support Ticket):

Những yêu cầu trên tạo nên một mạng nhện phụ thuộc chằng chịt giữa các quy tắc nghiệp vụ. Đây hoàn toàn không phải là một màn hình nhập liệu CRUD đơn giản!

Nếu cố tình dùng mẫu Active Record cho bài toán này, các quy tắc kiểm tra sẽ bị phân tán, sao chép vụn vặt ở khắp các tầng ứng dụng. Chỉ cần một lập trình viên sơ suất quên kiểm tra một điều kiện (ví dụ: cho phép agent bấm đóng một ticket đang bị escalate), trạng thái toàn vẹn của cả hệ thống sẽ lập tức bị phá hủy!

2.2. Phương thức cài đặt: Tách rời công nghệ hạ tầng

Mô hình miền (Domain Model) là một mô hình đối tượng kết hợp hữu cơ cả Hành vi (Behavior) lẫn Dữ liệu (Data). Các mẫu chiến thuật của DDD — Aggregates, Value Objects, Domain Events và Domain Services — chính là những viên gạch cấu thành nên mô hình này.

Tất cả các mẫu này đều chia sẻ một tôn chỉ bất di bất dịch: Đặt logic nghiệp vụ lên vị trí ưu tiên số 1!

3. Đối Tượng Giá Trị (Value Objects)

3.1. Định danh bằng giá trị & Sai lầm trường ColorId

Value Object là một đối tượng được định danh thuần túy bởi sự kết hợp của các giá trị bên trong nó.

Hãy xem xét một ví dụ kinh điển: Đối tượng Màu sắc (Color):

class Color
{
    int _red;
    int _green;
    int _blue;
}

Sự kết hợp cụ thể của 3 giá trị red, green, và blue tạo nên một màu sắc duy nhất. Nếu bạn thay đổi giá trị của một trường bất kỳ, bạn sẽ nhận được một màu sắc hoàn toàn mới. Không thể có hai màu sắc khác nhau lại có cùng giá trị RGB; và ngược lại, hai thực thể màu có cùng giá trị RGB chắc chắn là cùng một màu!

Do đó, chúng ta hoàn toàn không cần bất kỳ một trường định danh (ID) tường minh nào để phân biệt các màu sắc!

3.2. Mùi mã nguồn "Ám ảnh kiểu nguyên thủy" (Primitive Obsession)

Thói quen lạm dụng độc quyền các kiểu dữ liệu nguyên thủy có sẵn của ngôn ngữ lập trình (như string, int, decimal, dictionary) để biểu diễn các khái niệm nghiệp vụ được gọi là mùi mã nguồn Ám ảnh kiểu nguyên thủy (Primitive Obsession code smell).

Hãy xem xét cách thiết kế ngây thơ phổ biến sau:

class Person
{
    private int _id;
    private string _firstName;
    private string _lastName;
    private string _landlinePhone;
    private string _mobilePhone;
    private string _email;
    private int _heightMetric;
    private string _countryCode;
    ...
}

var dave = new Person(
    id: 30217,
    firstName: "Dave",
    lastName: "Ancelovici",
    landlinePhone: "023745001",
    mobilePhone: "0873712503",
    email: "dave@learning-ddd.com",
    heightMetric: 180,
    countryCode: "BG"
);

Trong cách viết trên, hầu hết các thuộc tính đều là string và giá trị được gán dựa trên... quy ước ngầm! Ví dụ: người ta ngầm quy ước countryCode phải là chuỗi 2 ký tự viết hoa. Hệ thống không thể tin tưởng người dùng luôn truyền đúng, vì vậy lớp Person buộc phải nhồi nhét hàng tá logic kiểm tra hợp lệ (validation) cho từng trường.

Hậu quả: Logic validation bị phân mảnh, trùng lặp khắp nơi và rất dễ bị các lập trình viên khác vô tình bỏ quên khi phát triển tính năng mới.

Giải pháp thanh lịch với Value Objects:

class Person
{
    private PersonId _id;
    private Name _name;
    private PhoneNumber _landline;
    private PhoneNumber _mobile;
    private EmailAddress _email;
    private Height _height;
    private CountryCode _country;
    ...
}

var dave = new Person(
    id: new PersonId(30217),
    name: new Name("Dave", "Ancelovici"),
    landline: PhoneNumber.Parse("023745001"),
    mobile: PhoneNumber.Parse("0873712503"),
    email: EmailAddress.Parse("dave@learning-ddd.com"),
    height: Height.FromMetric(180),
    country: CountryCode.Parse("BG")
);

3.3. Sức mạnh biểu đạt và Tính Bất Biến (Immutability)

Hãy nhìn vào sự lột xác của đoạn mã trên:

• Tính tường minh tuyệt đối: Biến country không cần phải đặt tên dài dòng là countryCode nữa, vì chính kiểu dữ liệu CountryCode đã tự nói lên bản chất của nó.
• Tự kiểm thực (Self-Validating): Không cần validate thủ công trước khi gán. Bản thân Value Object EmailAddress hay PhoneNumber không bao giờ cho phép một giá trị rác được khởi tạo!
• Đóng gói hành vi giàu có (Rich Behavior):

  // Chiều cao: tự động chuyển đổi hệ mét và hệ Anh
  var heightMetric = Height.Metric(180);
  var heightImperial = Height.Imperial(5, 3);
  bool firstIsHigher = heightMetric > heightImperial; // true
  
  // Số điện thoại: tự bóc tách mã quốc gia, phân loại máy bàn/di động
  var phone = PhoneNumber.Parse("+359877123503");
  string country = phone.Country; // "BG"
  string type = phone.PhoneType;   // "MOBILE"
  
  // Màu sắc: hành vi phối màu nghiệp vụ sinh ra màu mới
  var red = Color.FromRGB(255, 0, 0);
  var yellow = red.MixWith(Color.Green);

3.4. Khi nào nên dùng Value Objects?

Câu trả lời ngắn gọn nhất: BẤT CỨ KHI NÀO BẠN CÓ THỂ!

Quy tắc ngón tay cái: Hãy dùng Value Objects cho tất cả các phần tử trong miền nghiệp vụ dùng để mô tả đặc tính hoặc thuộc tính của các đối tượng khác (đặc biệt là thuộc tính của Entities).

4. Thực Thể (Entities)

4.1. Định danh tường minh và Tính khả biến

Thực thể (Entity) là khái niệm đối lập hoàn toàn với Value Object. Nó bắt buộc phải có một trường định danh tường minh (explicit ID) để phân biệt giữa các cá thể khác nhau.

Ví dụ: Một Con Người (Person). Hai người hoàn toàn có thể trùng tên họ, cùng ngày tháng năm sinh, cùng chiều cao cân nặng. Nhưng họ hiển nhiên là hai con người độc lập khác nhau! Do đó, chúng ta cần một trường định danh độc nhất (như Số Căn Cước Công Dân hoặc mã định danh PersonId) để phân biệt (xem Hình 6-2).

Hai điểm khác biệt cốt tử giữa Entity và Value Object:

1. Tính khả biến (Mutable): Trạng thái của một Entity được dự liệu là sẽ thay đổi liên tục theo thời gian trong suốt vòng đời của nó (người có thể đổi số điện thoại, đổi địa chỉ nhà, thăng chức). Trong khi đó, trường Id của Entity là bất biến tuyệt đối.
2. Thành phần cấu tạo: Các thuộc tính mô tả trạng thái của Entity thường được cấu thành từ chính các Value Objects!

4.2. Vì sao Entity không bao giờ đứng độc lập?

Bạn có thể nhận thấy một điều kỳ lạ: Ở phần đầu chương, tác giả không hề liệt kê "Entity" như một viên gạch độc lập của Domain Model. Đó hoàn toàn không phải là sự sơ suất!

Lý do là vì: Trong Domain-Driven Design, chúng ta KHÔNG BAO GIỜ cài đặt Entity một cách biệt lập, mà chỉ cài đặt Entity bên trong ngữ cảnh của mẫu hình AGGREGATE!

5. Tập Hợp Kết Hợp (Aggregates)

Một Aggregate bản thân nó cũng là một Entity: nó có trường định danh độc nhất và trạng thái của nó biến đổi theo thời gian. Thế nhưng, nó vượt trội hơn một Entity thông thường rất nhiều: Mục tiêu tối thượng của mẫu Aggregate là bảo vệ tính nhất quán dữ liệu tuyệt đối (Data Consistency)!

5.1. Ranh giới thực thi tính nhất quán (Consistency Enforcement Boundary)

Vì trạng thái của Entity có thể bị thay đổi, điều này mở ra nguy cơ dữ liệu bị làm sai hỏng từ bên ngoài. Để ngăn chặn thảm họa đó, mẫu Aggregate vạch ra một ranh giới thép ngăn cách giữa nội bộ của nó và thế giới bên ngoài: Aggregate chính là ranh giới thực thi tính nhất quán.

5.2. Ranh giới giao dịch: Một Aggregate trên một Transaction

Vì trạng thái của Aggregate chỉ có thể được biến đổi bởi chính nó, nên Aggregate cũng đồng thời đóng vai trò là Ranh Giới Giao Dịch (Transactional Boundary).

Mọi thay đổi đối với trạng thái của Aggregate bắt buộc phải được commit vào cơ sở dữ liệu dưới dạng một thao tác nguyên tử duy nhất (one atomic transaction): Hoặc tất cả thay đổi cùng được lưu, hoặc không có gì được lưu!

5.3. Cây phả hệ thực thể (Hierarchy of Entities)

Vậy nếu chúng ta thực sự cần biến đổi nhiều đối tượng cùng một lúc thì sao? Đây chính là lý do mẫu hình này có tên là Aggregate (Tập hợp kết hợp)!

Để hỗ trợ các thay đổi trên nhiều đối tượng phải diễn ra trong một transaction duy nhất, Aggregate được cấu trúc như một cây phả hệ gồm nhiều Entities và Value Objects cùng chia sẻ chung một ranh giới nhất quán giao dịch (xem Hình 6-3).

Ví dụ: Trong Aggregate Ticket, chúng ta có danh sách các thực thể con Message. Khi kiểm tra quy tắc tự động thu hồi ticket nếu agent chưa đọc tin nhắn quá 50% thời hạn, toàn bộ dữ liệu của Ticket và các Message con đều được đọc từ nguồn nhất quán mạnh mẽ và được bảo đảm không bị sửa đổi chéo:

public class Ticket
{
    ...
    List _messages;

    public void Execute(EvaluateAutomaticActions cmd)
    {
        // Kiểm tra đồng thời trạng thái của Ticket và các Message con
        if (this.IsEscalated && this.RemainingTimePercentage < 0.5
            && GetUnreadMessagesCount(for: AssignedAgent) > 0)
        {
            _agent = AssignNewAgent();
        }
    }
}

5.4. Tham chiếu Aggregate khác bằng ID

Vì tất cả các đối tượng bên trong Aggregate chia sẻ chung một ranh giới giao dịch, nên nếu một Aggregate phình to quá mức, hiệu năng và khả năng mở rộng của hệ thống sẽ sụp đổ nghiêm trọng!

Nguyên tắc vàng: Hãy giữ cho các Aggregate càng nhỏ càng tốt! Chỉ những dữ liệu nào mà logic nghiệp vụ của Aggregate bắt buộc phải ở trạng thái nhất quán mạnh (Strongly Consistent) thì mới được đưa vào bên trong Aggregate. Tất cả những dữ liệu có thể chấp nhận nhất quán sau cùng (Eventually Consistent) phải được đặt ra bên ngoài — thuộc về các Aggregate khác!

public class Ticket
{
    // Các đối tượng bên ngoài: chỉ tham chiếu bằng ID
    private UserId _customerId;
    private List _productIds;
    private UserId _assignedAgentId;

    // Các đối tượng bên trong ranh giới nhất quán mạnh:
    private List _messages;
    ...
}

5.5. Gốc Aggregate (Aggregate Root)

Trong một cây phả hệ gồm nhiều thực thể con, thực thể đóng vai trò là cửa ngõ giao tiếp công khai duy nhất của toàn bộ Aggregate được gọi là Gốc Aggregate (Aggregate Root) (xem Hình 6-5).

Nếu bạn muốn đánh dấu một tin nhắn là đã đọc, bạn không thể gọi trực tiếp message.WasRead = true, mà phải gửi lệnh qua Aggregate Root: ticket.Execute(new AcknowledgeMessage(messageId)).

5.6. Sự Kiện Miền (Domain Events)

Domain Event là một thông điệp mô tả một sự kiện nghiệp vụ quan trọng đã diễn ra trong quá khứ của miền nghiệp vụ.

Vì mô tả sự việc đã hoàn tất, tên của Domain Event bắt buộc phải được đặt ở thì quá khứ: TicketAssigned, TicketEscalated, MessageReceived.

6. Dịch Vụ Miền (Domain Services)

Trong thực tế, bạn sẽ gặp những logic nghiệp vụ quan trọng mà nó không thuộc về bất kỳ Aggregate hay Value Object cụ thể nào, hoặc nó cần đọc dữ liệu từ nhiều Aggregates khác nhau để tính toán. DDD đề xuất hiện thực hóa logic đó dưới dạng một Dịch Vụ Miền (Domain Service).

Đặc tính của Domain Service:

• Là một đối tượng phi trạng thái (Stateless).
• Nhiệm vụ chính là phối hợp đọc dữ liệu từ nhiều nguồn để thực hiện phép tính toán hoặc phân tích nghiệp vụ phức tạp.
• Lưu ý cốt tử: Domain Service hoàn toàn không phải là lỗ hổng để lách luật nguyên tắc một aggregate trên một transaction! Domain Service chỉ dùng để tính toán hoặc điều phối; việc sửa đổi trạng thái vẫn phải tuân thủ nghiêm ngặt ranh giới của từng Aggregate riêng lẻ.
• Lưu ý thuật ngữ: Domain Service trong DDD hoàn toàn không liên quan đến Microservices hay Service-Oriented Architecture (SOA). Nó chỉ đơn giản là một lớp chứa logic thuần túy.

7. Quản Lý Độ Phức Tạp: Lý Thuyết Bậc Tự Do

Tại sao việc sử dụng Aggregates và Value Objects lại giúp chúng ta kiểm soát được độ phức tạp của phần mềm?

Trong cuốn sách kinh điển The Choice, bậc thầy quản trị kinh doanh Eliyahu M. Goldratt đã đưa ra một định nghĩa xuất sắc: Độ phức tạp của một hệ thống được đo bằng độ khó khăn trong việc kiểm soát và dự đoán hành vi của hệ thống đó. Điều này được phản ánh thông qua BẬC TỰ DO (Degrees of Freedom) của hệ thống.

Bậc tự do là số lượng điểm dữ liệu độc lập tối thiểu cần có để mô tả trọn vẹn trạng thái của hệ thống. Hãy so sánh hai lớp đối tượng dưới đây:

public class ClassA
{
    public int A { get; set; }
    public int B { get; set; }
    public int C { get; set; }
    public int D { get; set; }
    public int E { get; set; }
}

public class ClassB
{
    private int _a, _d;
    public int A {
        get => _a;
        set { _a = value; B = value / 2; C = value / 3; }
    }
    public int B { get; private set; }
    public int C { get; private set; }
    public int D {
        get => _d;
        set { _d = value; E = value * 2; }
    }
    public int E { get; private set; }
}

8. Tổng Kết Chương 6

Chương 6 đã đưa chúng ta chạm vào trái tim tinh hoa nhất của Thiết Kế Hướng Miền:

• Domain Model: Mô hình đối tượng kết hợp cả dữ liệu và hành vi, đặt logic nghiệp vụ lên hàng đầu và sạch bóng mã nguồn công nghệ hạ tầng.
• Value Objects: Định danh bằng giá trị, bất biến (immutable), tự kiểm thực, đóng gói logic thao tác dữ liệu, an toàn đa luồng và loại bỏ Primitive Obsession.
• Entities: Cần trường định danh duy nhất (Id), có trạng thái khả biến và vòng đời kéo dài; luôn nằm trong Aggregate.
• Aggregates: Ranh giới thực thi tính nhất quán và ranh giới giao dịch; mỗi transaction chỉ sửa 1 aggregate; các aggregate khác chỉ tham chiếu qua ID; giao tiếp thông qua Aggregate Root và Domain Events.
• Domain Services: Đối tượng phi trạng thái chứa các thuật toán tính toán nghiệp vụ bắc cầu qua nhiều Aggregates.

9. Bài Tập & Trắc Nghiệm Đánh Giá Tri Thức (Exercises)

Hãy thử sức với 5 câu hỏi trắc nghiệm dưới đây để củng cố các nguyên lý cốt tử của Domain Model. Đáp án và giải thích được trích xuất trực tiếp từ Appendix B của tác giả Vlad Khononov.