Chương 9: Các Mẫu Giao Tiếp

Giới Thiệu: Mẫu Giao Tiếp Trong Hệ Thống Phân Tán

Trong các chương trước, chúng ta đã xem xét cách triển khai logic nghiệp vụ bên trong một thành phần và cách tổ chức kiến trúc nội bộ của nó. Tuy nhiên, không có phần mềm hiện đại nào tồn tại như một ốc đảo biệt lập. Trong kiến trúc hướng miền (Domain-Driven Design), các Bounded Contexts liên tục phải trao đổi thông tin, chia sẻ sự kiện và phối hợp thực hiện các quy trình nghiệp vụ xuyên suốt.

Chương này tập trung vào các mẫu thiết kế giao tiếp (Communication Patterns) — những giải pháp kỹ thuật đã được kiểm chứng qua thực tiễn giúp kết nối các thành phần một cách an toàn, tin cậy và linh hoạt, bất chấp những thách thức khắc nghiệt của môi trường mạng và hệ thống phân tán:

• Dịch chuyển mô hình (Model Translation): Cơ chế chuyển ngữ giữa các Ngôn ngữ Toàn hiện diện (Ubiquitous Languages) khác nhau của các Bounded Context tích hợp (Open-Host Service, Anticorruption Layer).
• Mẫu Hộp thư đi (Outbox Pattern): Giải pháp giải quyết triệt để vấn đề "Ghi kép" (Dual-write problem), đảm bảo mọi Domain Event được phát hành tin cậy và không bao giờ bị thất lạc.
• Mẫu Saga (Saga Pattern): Quản lý các giao dịch phân tán dài hạn (Long-running distributed transactions) và cơ chế bù trừ (Compensating transactions) mà không cần giao thức khóa 2 pha (2PC).
• Mẫu Quản lý Quy trình (Process Manager): Xây dựng các cỗ máy trạng thái (State Machines) điều phối những quy trình nghiệp vụ phức tạp có rẽ nhánh logic và tự động xử lý ngoại lệ.

Dịch Chuyển Mô Hình (Model Translation)

Trong Chương 4, chúng ta đã học rằng khi hai Bounded Context giao tiếp với nhau mà không thể áp dụng mẫu Conformist (Tuân thủ) hoặc Shared Kernel (Nhân dùng chung), một trong hai bên — hoặc cả hai — bắt buộc phải thực hiện việc chuyển đổi giữa hai mô hình nghiệp vụ khác biệt:

• Phía Bên Cung Cấp (Upstream): Áp dụng mẫu Open-Host Service (OHS) để chuyển đổi mô hình nội bộ thành một Published Language công khai.
• Phía Bên Tiêu Thụ (Downstream): Áp dụng mẫu Anticorruption Layer (ACL) để bảo vệ mô hình nội bộ của mình khỏi bị vấy bẩn bởi mô hình của bên ngoài.

1. Dịch Chuyển Mô Hình Phi Trạng Thái (Stateless Model Translation)

Trong dịch chuyển phi trạng thái, quá trình chuyển ngữ diễn ra "ngay tại chỗ" (on-the-fly) cho từng yêu cầu gửi đến hoặc phản hồi đi mà không cần lưu giữ thông tin trung gian nào. Logic dịch chuyển thường được đóng gói trong một đối tượng Proxy (Hình 9-1).

Giao Tiếp Đồng Bộ (Synchronous Communication)

Khi hai Bounded Context giao tiếp qua các giao thức đồng bộ (HTTP REST, gRPC), vị trí đặt bộ dịch chuyển phụ thuộc vào vai trò của hệ thống (Hình 9-2):

• Bên Cung Cấp (Upstream - OHS): Triển khai thông qua một API Gateway hoặc Reverse Proxy. Nó nhận các lời gọi API theo Published Language từ các client, chuyển đổi thành định dạng mà Bounded Context nội bộ hiểu được, và chuyển đổi phản hồi ngược lại. Nếu cần phục vụ nhiều thế hệ client khác nhau, API Gateway có thể phơi bày đồng thời nhiều phiên bản Published Language (v1, v2) mà không làm xáo trộn mã nguồn miền cốt lõi bên trong (Hình 9-3).

• Bên Tiêu Thụ (Downstream - ACL): Tầng ACL có thể được triển khai trực tiếp bên trong mã nguồn ứng dụng của Downstream (như một Adapter trong Ports & Adapters) hoặc tách thành một dịch vụ Proxy độc lập (Shared ACL Service) phục vụ chung cho nhiều Bounded Context tiêu thụ (Hình 9-4).

Giao Tiếp Bất Đồng Bộ (Asynchronous Communication)

Khi tích hợp bất đồng bộ qua Message Broker, bộ dịch chuyển mô hình đóng vai trò là một tiến trình lắng nghe thông điệp (Message Interceptor / Translator). Nó nhận sự kiện từ broker, chuyển đổi cấu trúc thông điệp, và chuyển tiếp thông điệp đã dịch vào hàng đợi nội bộ của Bounded Context (Hình 9-5).

2. Dịch Chuyển Mô Hình Có Trạng Thái (Stateful Model Translation)

Không phải lúc nào việc dịch chuyển cũng có thể hoàn tất trong một cái chớp mắt theo tỷ lệ 1:1. Trong nhiều kịch bản phức tạp, bộ dịch chuyển bắt buộc phải duy trì trạng thái (Stateful) để tích lũy dữ liệu qua nhiều lần gọi:

Gom Nhóm Yêu Cầu Theo Lô (Batching Requests)

Giả sử hệ thống nguồn liên tục phát sinh hàng ngàn cập nhật nhỏ giọt từng giây, nhưng hệ thống đích chỉ hỗ trợ API xử lý theo lô (Bulk Import) để tránh quá tải. Bộ dịch chuyển cần lưu tạm các thay đổi vào bộ đệm (bộ nhớ hoặc CSDL tạm) và chỉ gửi đi khi đạt đủ số lượng bản ghi hoặc sau một khoảng thời gian nhất định (Hình 9-7).

Thống Nhất Các Sự Kiện Rời Rạc (Unifying Incoming Events)

Một hệ thống nguồn phát ra nhiều sự kiện hạt mịn (fine-grained events) riêng rẽ: HeaderUpdated, ItemAdded, DiscountApplied. Nhưng Bounded Context đích chỉ quan tâm đến một sự kiện tổng hợp duy nhất: OrderUpdated.

Bộ dịch chuyển có trạng thái sẽ lắng nghe từng sự kiện, cập nhật trạng thái tạm thời, và khi điều kiện thỏa mãn, nó phát ra một sự kiện phong phú (rich event) hoàn chỉnh duy nhất cho phía downstream (Hình 9-8 & Hình 9-9).

Đơn Giản Hóa Mô Hình Tích Hợp Bằng CSDL Riêng

Để hỗ trợ dịch chuyển có trạng thái mạnh mẽ, tầng Anticorruption Layer thường được trang bị cơ sở dữ liệu riêng biệt để lưu trữ bảng tra cứu (mapping tables), trạng thái tích lũy và cấu trúc dữ liệu trung gian mà không làm phiền đến CSDL chính của Bounded Context (Hình 9-10).

Mẫu Hộp Thư Đi (Outbox Pattern)

Trong kiến trúc hướng sự kiện, một thao tác nghiệp vụ điển hình thường phải làm hai việc: cập nhật dữ liệu vào cơ sở dữ liệu và phát hành Domain Event ra Message Broker.

Tuy nhiên, đây là nguồn cơn của một trong những lỗi kinh điển và nguy hiểm nhất trong lập trình hệ thống: Vấn đề Ghi Kép (Dual-Write Problem).

Vấn Đề Ghi Kép (Dual-Write Problem) & Những Lời Giải Ngây Thơ

Hãy cùng phân tích hai cách triển khai phát hành sự kiện thường gặp và lý do tại sao cả hai đều dẫn đến thảm họa:

Sai lầm 1: Phát hành sự kiện ngay bên trong Aggregate

public class Campaign
{
    private List<DomainEvent> _events;
    private IMessageBus _messageBus;

    public void Deactivate(string reason)
    {
        foreach (var l in _locations.Values)
        {
            l.Deactivate();
        }
        IsActive = false;

        var newEvent = new CampaignDeactivated(_id, reason);
        _events.Add(newEvent);

        // NGUY HIỂM TỘT CÙNG: Bắn message ngay tại đây!
        _messageBus.Publish(newEvent);
    }
}

Tại sao đoạn code trên là một thảm họa?

• Sự kiện bị bắn ra mạng trước khi trạng thái mới của Aggregate được lưu vào CSDL. Các dịch vụ khác nhận được tin báo chiến dịch đã đóng, nhưng khi truy vấn CSDL thì chiến dịch vẫn đang mở!
• Nếu sau đó câu lệnh commit CSDL thất bại (do xung đột tương tranh, đứt kết nối, lỗi validation), giao dịch CSDL bị Rollback. Nhưng sự kiện đã bắn đi thì không thể rút lại được! Toàn bộ các hệ thống bên ngoài đã hành động dựa trên một sự kiện ma chưa từng tồn tại!

Sai lầm 2: Phát hành sự kiện sau khi commit trong Application Service

public class ManagementAPI
{
    public ExecutionResult DeactivateCampaign(CampaignId id, string reason)
    {
        try
        {
            var campaign = _repository.Load(id);
            campaign.Deactivate(reason);
            _repository.CommitChanges(campaign); // Lưu CSDL thành công

            // Sau khi lưu mới gửi sự kiện
            var events = campaign.GetUnpublishedEvents();
            foreach (var e in events)
            {
                _messageBus.Publish(e); // NẾU MÁY CHỦ SẬP TẠI ĐÂY THÌ SAO?
            }
            campaign.ClearUnpublishedEvents();
        }
        catch (Exception ex) { ... }
    }
}

Dù có vẻ an toàn hơn, đoạn code trên vẫn không chịu đựng được lỗi hệ thống:

Điều gì xảy ra nếu ngay sau dòng _repository.CommitChanges(campaign), máy chủ bị cúp điện, tiến trình bị kill (OOM), hoặc Message Broker gặp sự cố mất kết nối mạng? Cơ sở dữ liệu đã cập nhật xong, nhưng sự kiện vĩnh viễn không bao giờ được gửi đi! Hệ thống rơi vào trạng thái bất nhất không thể cứu vãn.

Thuật Toán Outbox: Giải Pháp Tuyệt Đối Tin Cậy

Mẫu Hộp Thư Đi (Outbox Pattern) giải quyết triệt để vấn đề trên bằng cách biến thao tác lưu trạng thái và ghi nhận sự kiện thành MỘT GIAO DỊCH NGUYÊN TỬ DUY NHẤT (Single Atomic Transaction) trong cơ sở dữ liệu (Hình 9-11):

Quy Trình 4 Bước Của Outbox:

1. Lưu nguyên tử: Trong cùng một Transaction CSDL, hệ thống cập nhật bản ghi của Aggregate và chèn đồng thời các Domain Event mới vào một bảng chuyên dụng gọi là Outbox (Hình 9-12). Hoặc cả hai cùng thành công, hoặc cả hai cùng rollback — không bao giờ có trạng thái lấp lửng!
2. Đọc sự kiện chưa gửi: Một tiến trình chuyển tiếp độc lập (Message Relay) đọc các sự kiện chưa gửi từ bảng Outbox.
3. Phát sóng: Message Relay phát hành sự kiện lên Message Broker.
4. Xác nhận: Sau khi Message Broker xác nhận đã nhận tin thành công (ACK), Message Relay đánh dấu sự kiện là published = true hoặc xóa bản ghi khỏi bảng Outbox.

{
  "campaign-id": "364b33c3-2171-446d-b652-8e5a7b2be1af",
  "state": {
    "name": "Autumn 2017",
    "publishing-state": "DEACTIVATED"
  },
  "outbox": [
    {
      "event-id": "e12a4b88-1122",
      "type": "campaign-deactivated",
      "reason": "Goals met",
      "published": false
    }
  ]
}

Cơ Chế Chuyển Tiếp Sự Kiện (Message Relay): Pull vs Push

Tiến trình Message Relay có thể trích xuất sự kiện chưa gửi từ CSDL theo hai phương thức:

Mẫu Saga (Saga Pattern)

Trong kiến trúc hướng dịch vụ và vi dịch vụ (Microservices), mỗi Bounded Context sở hữu một cơ sở dữ liệu riêng biệt. Chúng ta không thể sử dụng các giao dịch phân tán kiểu Two-Phase Commit (2PC) vì chúng tạo ra sự tắc nghẽn nghiêm trọng, làm giảm khả năng mở rộng và khiến các hệ thống phụ thuộc chặt chẽ vào nhau.

Mẫu Saga (Saga Pattern) ra đời để quản lý các giao dịch phân tán dài hạn xuyên suốt nhiều Bounded Context mà vẫn bảo toàn tính tự trị (autonomy) của từng thành phần.

Khái Niệm Cốt Lõi: Chuỗi Giao Dịch Cục Bộ & Cơ Chế Bù Trừ

Một Saga thực chất là một chuỗi các giao dịch cục bộ (sequence of local transactions):

• Mỗi giao dịch cục bộ chỉ cập nhật dữ liệu bên trong một Bounded Context duy nhất và phát ra một Domain Event.
• Saga lắng nghe Domain Event đó và gửi Command kích hoạt giao dịch cục bộ tiếp theo ở Bounded Context kế cận (Hình 9-13).

Giao Dịch Bù Trừ (Compensating Transactions)

Nếu một bước ở giữa quy trình thất bại (ví dụ: thẻ tín dụng bị từ chối), hệ thống không thể thực hiện câu lệnh ROLLBACK truyền thống xuyên suốt các database khác nhau được. Thay vào đó, Saga sẽ kích hoạt các Giao dịch Bù trừ (Compensating Transactions) theo chiều ngược lại để hoàn tác ngữ nghĩa của các bước đã thành công trước đó (ví dụ: hoàn tiền, giải phóng hàng giữ trong kho).

Triển Khai Mã Nguồn Chi Tiết: CampaignPublishingSaga

Hãy xem xét quy trình xuất bản một chiến dịch quảng cáo: khi chiến dịch được kích hoạt, hệ thống cần gửi thông tin quảng cáo sang dịch vụ xuất bản (Publishing Service). Khi dịch vụ xuất bản xác nhận hoặc từ chối, chiến dịch cập nhật lại trạng thái tương ứng:

public class CampaignPublishingSaga
{
    private readonly ICampaignRepository _repository;
    private readonly IList<IDomainEvent> _events;

    // Phản ứng khi có sự kiện CampaignActivated
    public void Process(CampaignActivated activated)
    {
        var campaign = _repository.Load(activated.CampaignId);
        var advertisingMaterials = campaign.GenerateAdvertisingMaterials();

        // Sinh sự kiện phát hành lệnh (CommandIssuedEvent) thay vì gọi trực tiếp mạng
        var commandIssuedEvent = new CommandIssuedEvent(
            target: Target.PublishingService,
            command: new SubmitAdvertisementCommand(activated.CampaignId, advertisingMaterials)
        );

        _events.Add(activated);
        _events.Add(commandIssuedEvent); // Lưu vào Outbox
    }

    // Phản ứng khi nhận được phản hồi PublishingConfirmed
    public void Process(PublishingConfirmed confirmed)
    {
        var commandIssuedEvent = new CommandIssuedEvent(
            target: Target.CampaignAggregate,
            command: new TrackConfirmation(confirmed.CampaignId, confirmed.ConfirmationId)
        );

        _events.Add(confirmed);
        _events.Add(commandIssuedEvent);
    }

    // Phản ứng khi nhận được phản hồi PublishingRejected (Bù trừ / Đánh dấu lỗi)
    public void Process(PublishingRejected rejected)
    {
        var commandIssuedEvent = new CommandIssuedEvent(
            target: Target.CampaignAggregate,
            command: new TrackRejection(rejected.CampaignId, rejected.RejectionReason)
        );

        _events.Add(rejected);
        _events.Add(commandIssuedEvent);
    }
}

Hãy chú ý cách thiết kế bậc thầy của tác giả: Saga không trực tiếp gọi HTTP hay gửi message ra ngoài! Thay vào đó, nó sinh ra đối tượng CommandIssuedEvent và đưa vào danh sách _events để Outbox Relay chịu trách nhiệm chuyển phát tin cậy. Điều này đảm bảo rằng ngay cả khi máy chủ sập ở bất kỳ bước nào, các Command vẫn sẽ được thực thi lại chuẩn xác và đầy đủ!

Tính Nhất Quán Trong Saga

Mặc dù Saga điều phối một giao dịch đa thành phần, trạng thái giữa các dịch vụ chỉ là Nhất quán sau (Eventually Consistent). Tuyệt đối không có tính nguyên tử tức thì (Atomic).

Mẫu Quản Lý Quy Trình (Process Manager)

Nhiều lập trình viên thường đánh đồng Saga và Process Manager là một. Mặc dù cả hai đều điều phối giao tiếp giữa các thành phần, chúng phục vụ hai mục đích hoàn toàn khác biệt:

Sự Khác Biệt Giữa Saga và Process Manager

Triển Khai Thực Tế: BookingProcessManager

Hãy quan sát ví dụ điển hình về quy trình Đặt chuyến công tác cho nhân viên (Trip Booking):

• Thuật toán định tuyến tìm đường bay tiết kiệm nhất và yêu cầu nhân viên phê duyệt.
• Nếu nhân viên đồng ý, hệ thống tiến hành đặt vé máy bay.
• Nếu nhân viên từ chối đường bay đó, hệ thống phải yêu cầu tìm đường bay khác và gửi quản lý trực tiếp phê duyệt.
• Sau khi đặt vé máy bay thành công, hệ thống tiếp tục đặt phòng khách sạn. Nếu hết phòng, vé máy bay phải bị hủy.

public class BookingProcessManager
{
    private readonly IList<IDomainEvent> _events = new List<IDomainEvent>();
    private BookingId _id;
    private Destination _destination;
    private TripDefinition _parameters;
    private EmployeeId _traveler;
    private Route _route;
    private IList<Route> _rejectedRoutes = new List<Route>();
    private IRoutingService _routing;

    // Khởi tạo tường minh quy trình
    public void Initialize(Destination destination, TripDefinition parameters, EmployeeId traveler)
    {
        _destination = destination;
        _parameters = parameters;
        _traveler = traveler;
        _route = _routing.Calculate(destination, parameters);

        var routeGenerated = new RouteGeneratedEvent(_id, _route);
        var command = new CommandIssuedEvent(new RequestEmployeeApproval(_traveler, _route));

        _events.Add(routeGenerated);
        _events.Add(command);
    }

    // Xử lý khi nhân viên đồng ý đường bay
    public void Process(RouteConfirmed confirmed)
    {
        var command = new CommandIssuedEvent(new BookFlights(_route, _parameters));
        _events.Add(confirmed);
        _events.Add(command);
    }

    // Xử lý rẽ nhánh khi nhân viên TỪ CHỐI đường bay
    public void Process(RouteRejected rejected)
    {
        var command = new CommandIssuedEvent(new RequestRerouting(_traveler, _route));
        _events.Add(rejected);
        _events.Add(command);
    }

    // Xử lý khi đường bay mới được người quản lý duyệt
    public void Process(ReroutingConfirmed confirmed)
    {
        _rejectedRoutes.Add(_route);
        _route = _routing.CalculateAltRoute(_destination, _parameters, _rejectedRoutes);

        var routeGenerated = new RouteGeneratedEvent(_id, _route);
        var command = new CommandIssuedEvent(new RequestEmployeeApproval(_traveler, _route));

        _events.Add(confirmed);
        _events.Add(routeGenerated);
        _events.Add(command);
    }

    // Sau khi vé máy bay được đặt thành công, chuyển sang bước đặt khách sạn
    public void Process(FlightBooked booked)
    {
        var command = new CommandIssuedEvent(new BookHotel(_destination, _parameters));
        _events.Add(booked);
        _events.Add(command);
    }
}

Trong thực tế, Process Manager thường được mô hình hóa và triển khai như một Aggregate (có thể dùng State-based hoặc Event Sourcing). Nó có định danh riêng, quản lý trạng thái vòng đời, và kiểm tra tính hợp lệ trước khi chuyển đổi trạng thái của quy trình.

Tổng Kết Chương

Chương 9 đã trang bị cho chúng ta bộ công cụ hoàn chỉnh để giải quyết bài toán giao tiếp liên thành phần trong các hệ thống phức tạp:

Như vậy, chúng ta đã đi trọn vẹn hành trình của Phần II: Chiến Thuật Thiết Kế (Tactical Design): từ việc mô hình hóa logic nghiệp vụ đơn giản đến phức tạp, tổ chức kiến trúc phần mềm, và kết nối giao tiếp phân tán.

Trong Chương 10: Các Nguyên Tắc Thiết Kế Thực Nghiệm (Design Heuristics), chúng ta sẽ được tiếp cận một "Bản đồ chỉ dẫn" tổng hợp cực kỳ giá trị, giúp bạn ngay lập tức đưa ra quyết định kiến trúc chuẩn xác nhất cho từng tình huống bài toán trong thực tế!

Bài Tập Ôn Tập & Thảo Luận Nghiệp Vụ

Hãy kiểm tra và củng cố tri thức về các mẫu giao tiếp qua 4 câu hỏi dưới đây kèm lời giải thích chính thức từ tác giả Vlad Khononov (Appendix B).