Kiến trúc Composable là gì? Cẩm nang MACH và API-first

Kiến trúc có khả năng ghép nối (Composable architecture) là cách xây dựng hệ thống phần mềm từ các thành phần độc lập, có thể thay thế được, giao tiếp với nhau qua API thay vì phụ thuộc vào một nền tảng “tất cả trong một”. Đây là nền tảng tư duy phía sau phong trào headless, đồng thời gắn chặt với Liên minh MACH, tổ chức thúc đẩy công nghệ doanh nghiệp mở và có khả năng ghép nối.

Dùng thử Apidog ngay hôm nay

Làm rõ nhanh trước khi triển khai

Từ “composable” thường bị dùng lẫn trong nhiều ngữ cảnh. Trong bài này, chỉ tập trung vào kiến trúc phần mềm.

• Kiến trúc có khả năng ghép nối (Composable architecture): lắp ráp ứng dụng từ các thành phần nghiệp vụ độc lập, tích hợp qua API.
• Cơ sở hạ tầng có khả năng ghép nối (Composable infrastructure): khái niệm hạ tầng/trung tâm dữ liệu, nơi compute, storage và network được gom chung rồi cấp phát theo nhu cầu.
• Khả năng ghép nối DeFi (DeFi composability): khái niệm blockchain, thường gọi là “money legos”, nơi các smart contract được xếp chồng để tạo sản phẩm tài chính mới.

Từ đây trở đi, “composable” nghĩa là kiến trúc phần mềm có khả năng ghép nối.

Kiến trúc có khả năng ghép nối là gì?

Một hệ thống composable được xây dựng từ các đơn vị mô-đun, tự chứa, mỗi đơn vị sở hữu một chức năng nghiệp vụ hoàn chỉnh. Bạn chọn công cụ phù hợp nhất cho từng chức năng, kết nối chúng qua API và có thể thay thế từng phần mà không phải viết lại toàn bộ hệ thống.

Đơn vị đó thường được gọi là khả năng nghiệp vụ đóng gói — Packaged Business Capability (PBC). Gartner định nghĩa PBC là các khả năng có thể triển khai độc lập, bao gồm dữ liệu nghiệp vụ, logic và quy trình tự chứa, tương tác với ứng dụng khác thông qua API và kênh sự kiện.

Ví dụ:

• PBC thanh toán sở hữu phương thức thanh toán, kiểm tra gian lận, hoàn tiền và tranh chấp.
• PBC tìm kiếm sở hữu indexing, ranking và xử lý truy vấn.
• PBC kho hàng sở hữu tồn kho, giữ hàng và cập nhật trạng thái.

Điểm quan trọng: mỗi PBC cung cấp API cấp nghiệp vụ, không expose trực tiếp bảng cơ sở dữ liệu nội bộ.

Ví dụ đơn giản về contract của PBC thanh toán:

openapi: 3.0.3
info:
  title: Payment Capability API
  version: 1.0.0

paths:
  /payments:
    post:
      summary: Tạo giao dịch thanh toán
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - orderId
                - amount
                - currency
              properties:
                orderId:
                  type: string
                amount:
                  type: number
                currency:
                  type: string
                  example: VND
      responses:
        "201":
          description: Giao dịch đã được tạo
        "400":
          description: Dữ liệu không hợp lệ

Contract này cho phép frontend, service đơn hàng hoặc đối tác tích hợp với PBC thanh toán mà không cần biết hệ thống thanh toán dùng database, queue hay provider nào phía sau.

Composable so với monolith

Monolith gom nhiều khả năng vào một ứng dụng triển khai chung, thường dùng chung một cơ sở dữ liệu. Cách này dễ bắt đầu, nhưng càng lớn càng khó thay đổi. Kiến trúc composable tách các khả năng thành những phần độc lập để từng phần có thể phát triển, triển khai và thay thế riêng.

Nếu bạn đã đọc về monolith so với microservices, composable có thể xem là cách nhìn ở cấp nghiệp vụ: microservices là phân tách kỹ thuật, còn PBC là phân tách theo miền nghiệp vụ.

Khía cạnh	Monolith	Kiến trúc có khả năng ghép nối
Đơn vị thay đổi	Toàn bộ ứng dụng	Một PBC
Dữ liệu	Một cơ sở dữ liệu chung	Mỗi khả năng sở hữu dữ liệu riêng
Lựa chọn nhà cung cấp	Một nền tảng, chấp nhận tất cả	Best-of-breed cho từng khả năng
Giao diện người dùng	Gắn chặt với backend	Tách rời, nhiều kênh
Tích hợp	Gọi hàm nội bộ	API và sự kiện
Rủi ro bị khóa chặt	Cao	Thấp hơn, thành phần có thể thay thế

Đánh đổi chính: composable cho bạn khả năng linh hoạt và thay thế, nhưng cũng tạo thêm nhiều thành phần cần tích hợp, giám sát và quản lý contract.

MACH: bộ nguyên tắc phổ biến cho kiến trúc composable

Khi một nhóm nói “composable”, họ thường nói đến kiến trúc đi theo nguyên tắc MACH. MACH là viết tắt của:

• M — Microservices: các khả năng được xây dựng thành những service nhỏ, có thể triển khai độc lập.
• A — API-first: mọi chức năng quan trọng được cung cấp qua API. UI chỉ là một consumer của API.
• C — Cloud-native: các thành phần được thiết kế cho môi trường cloud, có thể scale linh hoạt và tận dụng managed services.
• H — Headless: frontend được tách khỏi backend, cho phép nhiều client dùng chung API.

Composable, headless và MACH không phải là từ đồng nghĩa:

• Headless là tách frontend khỏi backend.
• MACH là một bộ nguyên tắc cụ thể để xây dựng hệ thống mở, composable.
• Composable là khái niệm rộng hơn: hệ thống được ghép từ các khả năng độc lập.

Cách thiết kế hệ thống composable theo hướng API-first

Trong kiến trúc composable, API là lớp tích hợp giữ các thành phần độc lập lại với nhau. Vì mỗi PBC sở hữu dữ liệu và logic riêng, contract API là thứ duy nhất mà các thành phần khác có thể dựa vào.

Một quy trình thực tế có thể đi theo các bước sau.

Bước 1: Xác định ranh giới nghiệp vụ

Trước khi tạo service, hãy tách hệ thống theo khả năng nghiệp vụ.

Ví dụ với hệ thống thương mại điện tử:

• Catalog
• Search
• Cart
• Checkout
• Payment
• Inventory
• Order
• Notification

Đừng tách service theo bảng database như users, orders, payments quá sớm. Hãy hỏi: “Khả năng nghiệp vụ nào có thể thay đổi, triển khai hoặc thay thế độc lập?”

Bước 2: Xác định ownership dữ liệu

Mỗi PBC nên sở hữu dữ liệu của nó.

Ví dụ:

• Inventory sở hữu tồn kho.
• Payment sở hữu trạng thái thanh toán.
• Order sở hữu vòng đời đơn hàng.
• Search có thể giữ index riêng, nhưng không phải nguồn dữ liệu gốc.

Tránh để nhiều PBC cùng ghi trực tiếp vào một database chung. Nếu cần đồng bộ, ưu tiên API hoặc event.

Bước 3: Thiết kế contract trước khi viết code

Với phát triển API-first, contract được thiết kế trước. Backend, frontend và QA có thể làm song song dựa trên cùng một đặc tả.

Ví dụ một endpoint cấp nghiệp vụ:

POST /checkout/session
Content-Type: application/json

{
  "cartId": "cart_123",
  "customerId": "cus_456",
  "shippingAddressId": "addr_789"
}

Response:

{
  "checkoutSessionId": "chk_001",
  "status": "READY_FOR_PAYMENT",
  "paymentOptions": [
    {
      "type": "CARD",
      "provider": "payment-pbc"
    }
  ]
}

API này thể hiện intent nghiệp vụ: tạo phiên checkout. Consumer không cần biết checkout gọi inventory, payment hay shipping như thế nào phía sau.

Bước 4: Dùng mock server để phát triển song song

Khi contract đã ổn định, mock server giúp frontend hoặc service consumer tích hợp ngay cả khi backend chưa hoàn tất.

Ví dụ frontend có thể gọi:

async function createCheckoutSession(cartId: string) {
  const response = await fetch("https://mock.example.com/checkout/session", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      cartId,
      customerId: "cus_456",
      shippingAddressId: "addr_789"
    })
  });

  if (!response.ok) {
    throw new Error("Không thể tạo checkout session");
  }

  return response.json();
}

Điều này giảm tình trạng “frontend chờ backend” hoặc “backend xong nhưng contract sai”.

Bước 5: Kiểm thử contract trong CI

Một thay đổi nhỏ trong API có thể phá vỡ nhiều consumer. Vì vậy, contract test nên là một phần của pipeline.

Tối thiểu, mỗi PBC nên có:

• Test cho request/response schema.
• Test cho status code chính.
• Test cho backward compatibility.
• Test cho lỗi phổ biến như 400, 401, 404, 409.
• Test cho timeout và retry behavior nếu có tích hợp liên service.

Ví dụ checklist trước khi merge thay đổi API:

[ ] Endpoint mới đã có OpenAPI spec
[ ] Response không xóa field đang được consumer dùng
[ ] Error response có format nhất quán
[ ] Mock response đã được cập nhật
[ ] Tài liệu API đã được publish
[ ] Test API chạy trong CI

Khi API trở thành sản phẩm

Trong monolith, module nội bộ có thể gọi trực tiếp hàm hoặc truy cập chung database. Trong hệ thống composable, shortcut đó không còn an toàn. API trở thành giao diện sản phẩm mà team khác, frontend khác hoặc đối tác bên ngoài thực sự sử dụng.

Đó là lý do API là sản phẩm không chỉ là khẩu hiệu. Một API kém thiết kế sẽ tạo chi phí cho mọi consumer phía sau.

Một API tốt nên có:

• Naming nhất quán.
• Resource và action rõ ràng.
• Error response có cấu trúc.
• Versioning có kế hoạch.
• Tài liệu dễ dùng.
• Mock và test đi kèm.
• Chính sách backward compatibility rõ ràng.

Ví dụ error response nên thống nhất:

{
  "error": {
    "code": "PAYMENT_METHOD_DECLINED",
    "message": "Phương thức thanh toán bị từ chối.",
    "requestId": "req_abc123"
  }
}

Không nên mỗi PBC trả lỗi theo một kiểu khác nhau.

Lợi ích và đánh đổi

Lợi ích chính của kiến trúc composable:

• Best-of-breed: chọn công cụ tốt nhất cho từng khả năng thay vì phụ thuộc vào một suite duy nhất.
• Thay đổi độc lập: nâng cấp hoặc thay thế một PBC mà ít ảnh hưởng đến phần còn lại.
• Giảm vendor lock-in: các thành phần có thể hoán đổi nếu contract được quản lý tốt.
• Team làm việc song song: mỗi nhóm có thể triển khai theo nhịp riêng.
• Đa kênh: một bộ API có thể phục vụ web, mobile, kiosk, voice hoặc partner integration.

Chi phí cần tính trước:

• Chi phí tích hợp: nhiều thành phần hơn đồng nghĩa nhiều kết nối hơn.
• Kỷ luật contract: thay đổi phá vỡ API có thể lan rộng.
• Độ phức tạp vận hành: logging, tracing, auth, monitoring và versioning trải trên nhiều service.
• Thiết kế ban đầu: cần đầu tư vào boundary, ownership và API contract trước khi code.

Composable phù hợp khi bạn cần linh hoạt, mở rộng và phục vụ nhiều kênh. Nếu một monolith sạch đã đủ, composable có thể là quá mức.

Apidog phù hợp ở đâu trong kiến trúc composable?

Apidog không biến kiến trúc của bạn thành composable. Nó không phải CMS, nền tảng thương mại điện tử, API gateway hay nền tảng MACH. Vai trò của Apidog nằm ở chữ A — API-first: lớp contract mà các thành phần độc lập phụ thuộc vào.

Vì API là giao diện giữa các PBC, contract cần được thiết kế, kiểm thử, mô phỏng và tài liệu hóa tốt. Apidog hỗ trợ các công việc đó trong một quy trình API-first:

• Thiết kế contract trước: định nghĩa API bằng OpenAPI trước khi backend triển khai.
• Mock server: cho phép team frontend, backend và partner làm song song dựa trên contract. Xem thêm về mock API.
• Kiểm thử API: xác thực request, response và behavior của API trước khi release.
• Tài liệu hóa API: giúp consumer hiểu nhanh cách tích hợp.
• Chạy test không cần GUI: Apidog CLI có thể chạy test API trong CI.
• Quản lý từ công cụ hiện có: thông qua MCP, bạn có thể điều khiển dự án API từ AI agent hoặc IDE.

Nếu hệ thống của bạn đi theo mô hình API là sản phẩm, lớp API contract là nơi cần đầu tư nghiêm túc. Bạn có thể tải xuống Apidog để thiết kế và mô phỏng contract trước khi backend hoàn tất.

Khi nào nên áp dụng kiến trúc composable?

Hãy cân nhắc kiến trúc composable khi nhiều điều sau đúng với hệ thống của bạn:

• Bạn cần phục vụ nhiều kênh: web, mobile, cửa hàng, voice, đối tác.
• Các khả năng nghiệp vụ thay đổi với tốc độ khác nhau.
• Bạn muốn chọn công cụ tốt nhất cho từng khả năng.
• Vendor lock-in là rủi ro thật sự.
• Nhiều team cần triển khai độc lập.
• Bạn có đủ kỷ luật để quản lý API contract, versioning, testing và observability.

Không nên vội dùng composable nếu:

• Team nhỏ, sản phẩm còn đang tìm product-market fit.
• Domain chưa ổn định.
• Bạn chưa có quy trình test API và monitoring tốt.
• Một monolith sạch vẫn đáp ứng nhu cầu hiện tại.

Một cách tiếp cận thực tế là bắt đầu bằng monolith có ranh giới rõ, sau đó tách dần các PBC có nhu cầu thay đổi hoặc scale độc lập.

Checklist triển khai composable architecture

Dùng checklist này trước khi tách một capability thành PBC riêng:

[ ] Capability có ranh giới nghiệp vụ rõ ràng
[ ] Có owner/team chịu trách nhiệm
[ ] Dữ liệu thuộc về capability đã được xác định
[ ] API contract đã được thiết kế trước
[ ] Có OpenAPI spec
[ ] Có mock server cho consumer
[ ] Có test API trong CI
[ ] Có tài liệu API cho consumer
[ ] Có chiến lược versioning
[ ] Có logging, metrics và tracing
[ ] Có kế hoạch xử lý lỗi, retry và timeout
[ ] Có phương án rollback khi release lỗi

Nếu nhiều mục chưa có câu trả lời, hãy xử lý chúng trước khi tăng thêm số lượng service.

Các câu hỏi thường gặp

Kiến trúc composable có giống microservices không?

Không, nhưng có chồng lấn. Microservices là cách kỹ thuật để phân tách hệ thống thành các service nhỏ có thể triển khai độc lập. Kiến trúc composable phân tách theo khả năng nghiệp vụ, thường thông qua PBC, và nhấn mạnh việc dùng các thành phần best-of-breed có thể thay thế được qua API.

Microservices thường là cách triển khai backend cho hệ thống composable. Để hiểu rõ hơn, xem bài monolith so với microservices.

Khác biệt giữa composable và headless là gì?

Headless nghĩa là frontend được tách khỏi backend, cho phép nhiều client dùng cùng API. Composable rộng hơn: toàn bộ hệ thống được lắp từ các khả năng độc lập, kết nối bằng API.

Bạn có thể có một CMS headless nhưng chưa chắc toàn bộ kiến trúc đã composable.

PBC là gì?

PBC, hay Packaged Business Capability, là một đơn vị tự chứa sở hữu một chức năng nghiệp vụ hoàn chỉnh, bao gồm dữ liệu, logic và API. Ví dụ: tìm kiếm, thanh toán, kho hàng, thông báo.

Một PBC tốt không chỉ là một service nhỏ. Nó là một capability có ý nghĩa nghiệp vụ, có API rõ ràng và có thể triển khai độc lập.

Tôi có cần nền tảng API để chuyển sang composable không?

Bạn cần một cách để thiết kế, kiểm thử, mô phỏng và giữ cho API contract ổn định. Công cụ có thể là một bộ tool riêng lẻ hoặc một nền tảng tích hợp. Vấn đề cốt lõi không phải là tên sản phẩm, mà là kỷ luật quản lý contract.

Tóm tắt

Kiến trúc có khả năng ghép nối là cách xây dựng hệ thống từ các khả năng độc lập, có thể thay thế, kết nối qua API. Headless, MACH và microservices là các khái niệm liên quan nhưng không đồng nghĩa.

Điểm quan trọng nhất khi triển khai composable là: contract chính là hệ thống. Nếu API không ổn định, tài liệu kém hoặc thiếu test, toàn bộ lợi ích về khả năng thay thế, đa kênh và giảm phụ thuộc sẽ khó đạt được.

Thiết kế API trước, mock sớm, kiểm thử trong CI và tài liệu hóa rõ ràng với một công cụ như Apidog là nền tảng thực tế để triển khai composable architecture an toàn hơn.