Chương 11: Tiến Hóa Các Quyết Định Thiết Kế

Giới Thiệu: Sự Tiến Hóa Của Các Quyết Định Thiết Kế

Trong suốt hai phần đầu của cuốn sách, chúng ta đã tiếp cận việc thiết kế phần mềm như một quá trình phân tích tĩnh: xác định các Subdomain, vạch ra các Bounded Context, lựa chọn mẫu logic nghiệp vụ và kiến trúc phù hợp.

Thế nhưng, thế giới kinh doanh thực tế không bao giờ đứng yên:

• Các đối thủ cạnh tranh mới liên tục xuất hiện, làm xói mòn lợi thế độc quyền của doanh nghiệp.
• Các công nghệ mới ra đời biến những bài toán hóc búa thành những dịch vụ điện toán đám mây có sẵn.
• Quy mô tổ chức phình to: từ một nhóm 5 lập trình viên trong phòng khách trở thành hàng trăm kỹ sư làm việc tại nhiều văn phòng ở các múi giờ khác nhau.
• Sự thấu hiểu về miền nghiệp vụ (Domain Knowledge) của đội ngũ kỹ sư ngày càng sâu sắc qua từng năm tháng vận hành.

Chương 11 mở ra Phần III: Triển Khai Thực Tiễn (Applied DDD) bằng cách trả lời câu hỏi cốt tử: Làm thế nào để nhận biết thời điểm một quyết định thiết kế trong quá khứ đã trở nên lỗi thời, và làm thế nào để tái cấu trúc (refactor) hệ thống một cách an toàn, mượt mà mà không làm gián đoạn dòng chảy kinh doanh?

Sự Chuyển Dịch Loại Subdomain (Subdomain Shifts)

Một sai lầm tai hại là coi việc gán nhãn Core, Supporting hay Generic cho một Subdomain là quyết định vĩnh viễn. Trên thực tế, loại của một Subdomain liên tục dịch chuyển qua lại theo chu kỳ phát triển của thị trường và chiến lược kinh doanh (Hình 11-1).

1. Từ Core Sang Generic (Thương Mại Hóa Thị Trường)

Một tính năng ban đầu là phát minh đột phá mang lại lợi thế cạnh tranh độc quyền cho công ty (Core Subdomain). Nhưng theo thời gian, thị trường bắt kịp, các đối thủ sao chép, và các nhà cung cấp phần mềm bên thứ ba cho ra đời các sản phẩm thương mại hoàn chỉnh (COTS) hoặc dịch vụ SaaS.

• Ví dụ thực tế: Vào đầu những năm 2000, một thuật toán tìm kiếm sản phẩm thông minh trên trang thương mại điện tử là một Core Subdomain đắt giá. Ngày nay, các giải pháp tìm kiếm và đề xuất sản phẩm chuyên dụng (như Algolia, Elasticsearch) đã biến bài toán này thành một Generic Subdomain.
• Hành động kiến trúc: Đừng tiếp tục lãng phí tài nguyên kỹ sư tinh nhuệ để tự code lại từ đầu! Hãy mạnh dạn thay thế khối mã nguồn nội bộ cồng kềnh bằng một dịch vụ bên thứ ba đã được kiểm chứng.

2. Từ Generic Sang Core (Bài Học Kinh Điển Từ Amazon Web Services)

Một tác vụ vốn là nhu cầu chung của mọi doanh nghiệp bỗng nhiên được một công ty đầu tư nghiên cứu và tối ưu hóa đến mức xuất chúng, biến nó thành lợi thế cạnh tranh cốt lõi tạo ra doanh thu hàng tỷ đô la!

3. Từ Supporting Sang Core (Khám Phá Cơ Hội Kinh Doanh Mới)

Một tính năng hỗ trợ nhỏ ban đầu được viết bằng Transaction Script hoặc Active Record đơn giản. Thế nhưng, người dùng lại đặc biệt yêu thích tính năng đó, và ban lãnh đạo quyết định đầu tư để biến nó thành vũ khí cạnh tranh mới.

4. Từ Core Sang Supporting

Một giải pháp từng mang tính sống còn nhưng bị thị trường đơn giản hóa hoặc các quy định pháp luật chuẩn hóa (ví dụ: một phương thức tính thuế đặc thù bị bãi bỏ), khiến các thuật toán phức tạp trở thành các phép tính số học bình thường.

Tiến Hóa Tích Hợp Bounded Context (Strategic Evolution)

Không chỉ có các Subdomain thay đổi bản chất, mối quan hệ tích hợp giữa các Bounded Context trên Context Map cũng phải tiến hóa khi tổ chức phát triển:

1. Từ Partnership Sang Customer-Supplier

Khi công ty còn là một startup nhỏ (20-30 người), hai nhóm kỹ sư ngồi chung một phòng có thể dễ dàng hợp tác theo kiểu Partnership: không cần hợp đồng API khắt khe, chỉ cần quay sang nói chuyện trực tiếp, sửa code cùng nhau và deploy đồng thời.

Tuy nhiên, khi công ty tăng trưởng lên hàng trăm kỹ sư và công việc của một Bounded Context được chuyển giao sang một văn phòng ở quốc gia khác (khác biệt về múi giờ, văn hóa và kênh giao tiếp), mối quan hệ Partnership ad-hoc sẽ sụp đổ. Các nhóm sẽ liên tục dẫm chân lên nhau.

Giải pháp tiến hóa: Chuyển dịch sang mô hình Khách hàng - Nhà cung cấp (Customer-Supplier) có tổ chức chính quy hơn:

• Bên Upstream xây dựng Open-Host Service (OHS) với phiên bản API rõ ràng và cam kết SLA.
• Bên Downstream tự bảo vệ mình bằng Anticorruption Layer (ACL).

2. Từ Customer-Supplier Sang Đường Ai Nấy Đi (Separate Ways)

Đôi khi, khoảng cách địa lý, sự chậm trễ trong quy trình phê duyệt hoặc sự bất đồng văn hóa/chính trị giữa các bộ phận khiến chi phí hợp tác (Collaboration Overhead) trở nên quá đắt đỏ:

Chi phí Hợp tác & Chờ đợi > Chi phí Tự Triển khai Riêng (Duplication Cost)

Khi đó, quyết định sáng suốt nhất là chuyển sang mẫu Đường Ai Nấy Đi (Separate Ways): bên Downstream tự viết lại chức năng đó cho riêng mình thay vì tiếp tục phụ thuộc và chờ đợi bên Upstream.

Hướng Dẫn Tái Cấu Trúc Chiến Thuật (Tactical Refactoring)

Khi một Subdomain trở nên phức tạp hơn, làm thế nào để nâng cấp mã nguồn từ mẫu đơn giản lên mẫu nâng cao từng bước một mà không làm sập hệ thống?

1. Tái Cấu Trúc Từ Active Record Sang Domain Model

Quá trình chuyển đổi từ mô hình thiếu máu (Anemic Domain Model / Active Record) sang Mô Hình Miền giàu tính đóng gói (Rich Domain Model) diễn ra qua 4 bước:

Bước 1: Nhận diện logic nghiệp vụ bị rò rỉ ra ngoài

Trong mô hình Active Record, các thực thể chỉ chứa getter/setter dữ liệu, trong khi logic biến đổi trạng thái lại nằm rải rác ở Service Layer:

public class PlayerService
{
    public void ApplyBonus(Guid playerId, int percentage)
    {
        var player = _repository.Load(playerId);
        // Logic biến đổi điểm thưởng bị lộ ra ngoài Service
        player.Points *= 1 + percentage / 100.0;
        _repository.Save(player);
    }
}

Bước 2: Di chuyển logic vào bên trong ranh giới thực thể

Đóng gói trường dữ liệu (private setter) và đưa logic tính toán vào phương thức nghiệp vụ của chính thực thể đó:

public class Player
{
    public Guid Id { get; private set; }
    public int Points { get; private set; }

    // Logic nghiệp vụ tự bảo vệ trạng thái nội bộ
    public void ApplyBonus(int percentage)
    {
        this.Points *= 1 + percentage / 100.0;
    }
}

Bước 3: Thiết lập ranh giới Aggregate & Bất biến

Tìm kiếm ranh giới giao dịch nhỏ nhất cần duy trì tính nhất quán mạnh (Strong Consistency). Gom các thực thể phụ thuộc chặt chẽ vào một Aggregate. Đảm bảo các Aggregate bên ngoài chỉ được tham chiếu qua ID (Identity Reference).

Bước 4: Thiết lập Aggregate Root làm cổng vào duy nhất

Chuyển tất cả các phương thức sửa đổi của các đối tượng con bên trong thành private hoặc internal. Mọi tương tác từ thế giới bên ngoài bắt buộc phải đi qua Aggregate Root.

2. Tái Cấu Trúc Từ Domain Model Sang Event-Sourced Domain Model

Thách thức lớn nhất khi chuyển từ Domain Model (lưu trạng thái hiện tại) sang Event Sourcing là: Làm thế nào để di chuyển dữ liệu của các thực thể hiện hữu — vốn chỉ có trạng thái tĩnh và hoàn toàn không có lịch sử sự kiện trong quá khứ?

Vlad Khononov cung cấp hai chiến lược di chuyển dữ liệu chuẩn mực:

Chiến Lược A: Tái Tạo Sự Kiện Quá Khứ (Generating Past Transitions)

Dựa trên trạng thái hiện tại trong CSDL cũ, chúng ta viết một kịch bản suy diễn logic để sinh ra một chuỗi sự kiện phỏng đoán hợp lý:

[
  { "event-type": "lead-initialized", "lead-id": 12, "name": "Shauna Mercia" },
  { "event-type": "contacted", "lead-id": 12 },
  { "event-type": "order-submitted", "lead-id": 12 },
  { "event-type": "payment-confirmed", "lead-id": 12, "status": "converted" }
]

• Ưu điểm: Chuỗi sự kiện trông tự nhiên, các phép chiếu (Projections) không cần sửa đổi logic xử lý.
• Nhược điểm: Lịch sử không có thật 100%. Chúng ta không thể biết nhân viên đã gọi bao nhiêu cuộc gọi trước khi chốt đơn.

Chiến Lược B: Mô Hình Hóa Sự Kiện Di Trú (Modeling Migration Events)

Thay vì phỏng đoán sự kiện quá khứ, chúng ta công khai thừa nhận sự thiếu hụt dữ liệu lịch sử bằng một Domain Event đặc biệt: migrated-from-legacy:

{
  "lead-id": 12,
  "event-id": 0,
  "event-type": "migrated-from-legacy",
  "first-name": "Shauna",
  "last-name": "Mercia",
  "status": "converted",
  "migrated-at": "2021-06-15T08:00:00.00Z"
}

• Ưu điểm: Trung thực tuyệt đối về mặt dữ liệu, không bao giờ gây hiểu lầm cho các thuật toán phân tích sau này.
• Nhược điểm: Vết tích của hệ thống cũ sẽ nằm vĩnh viễn trong Event Store, và tất cả các phép chiếu (Projections / CQRS) đều phải có thêm một hàm Apply(MigratedFromLegacy @event) để khởi tạo trạng thái ban đầu.

Chia Nhỏ Bounded Context (Splitting Bounded Contexts)

Ở Chương 10, chúng ta đã được khuyên nên bắt đầu bằng ranh giới Bounded Context rộng (thường là một khối Monolith theo mô-đun). Vậy khi nào thì nên chia nhỏ nó ra thành nhiều Bounded Context độc lập?

Khi Đội Ngũ Kỹ Thuật Phình To (Team Growth)

Theo quy tắc vàng của DDD: Một Bounded Context chỉ nên được phát triển và sở hữu bởi DUY NHẤT MỘT ĐỘI NGŨ KỸ SƯ!

Khi công ty tuyển dụng thêm nhiều nhân sự mới và thành lập các nhóm phát triển chuyên trách (Team Alpha, Team Beta, Team Gamma), việc nhiều nhóm cùng sửa đổi trên một codebase duy nhất sẽ gây ra tắc nghẽn nghiêm trọng (Merge conflicts, chờ đợi code review, deploy chồng chéo).

Đó là thời điểm hoàn hảo để chia tách Bounded Context rộng ban đầu thành các Bounded Context hẹp hơn — mỗi nhóm sở hữu trọn vẹn một Bounded Context riêng biệt (Hình 11-2).

Tối Ưu Hóa Ranh Giới Subdomain (Optimizing Subdomains' Boundaries)

Khi một doanh nghiệp mở rộng quy mô, một Subdomain ban đầu tưởng chừng đơn nhất có thể bộc lộ ra nhiều khía cạnh nghiệp vụ với các đặc tính vận hành hoàn toàn trái ngược nhau.

Thay vì duy trì một mô hình "ôm đồm mọi thứ nhưng chẳng giỏi thứ gì" (jack of all trades, master of none), chúng ta tái cấu trúc để tối ưu hóa lại ranh giới của các Subdomain (Hình 11-3): tách phần logic cốt lõi thật sự thành Core Subdomain độc lập, và đưa các tác vụ phụ trợ ra thành các Supporting Subdomain riêng biệt.

Tổng Kết Chương

Chương 11 đã chỉ ra rằng kiến trúc phần mềm là một cuộc hành trình tiến hóa liên tục:

• Nhận diện sự thay đổi: Luôn quan sát sự dịch chuyển của các Subdomain (từ Core sang Generic hoặc từ Supporting sang Core).
• Tiến hóa tích hợp: Điều chỉnh mối quan hệ trên Context Map (Partnership → Customer-Supplier → Separate Ways) dựa trên sự biến động của cơ cấu tổ chức và chi phí hợp tác.
• Tái cấu trúc bài bản: Từng bước nâng cấp mô hình từ Active Record lên Domain Model bằng cách đóng gói bất biến, và chuyển sang Event Sourcing bằng các kỹ thuật di trú dữ liệu an toàn.
• Chia tách đúng thời điểm: Chỉ phân rã Bounded Context khi quy mô đội ngũ thực sự đòi hỏi hoặc khi các lát cắt nghiệp vụ đã chứng minh được tính độc lập rõ ràng.

Nhưng làm thế nào để cả đội ngũ — bao gồm kỹ sư, chuyên gia miền nghiệp vụ và các nhà quản lý — có thể cùng nhau ngồi lại, khám phá toàn cảnh dòng chảy sự kiện và phát hiện ra những ranh giới tiềm ẩn một cách nhanh chóng nhất chỉ trong vài giờ đồng hồ?

Câu trả lời nằm ở phương pháp hợp tác trực quan đỉnh cao mang tên EventStorming — chủ đề vô cùng thú vị của Chương 12!

Bài Tập Ôn Tập & Thảo Luận Thực Tiễn

Dưới đây là 5 câu hỏi ôn tập và tình huống chiến lược kèm lời giải chi tiết từ tác giả Vlad Khononov (Appendix B).