Tại sao tôi không dùng Drupal Commerce chỉ để làm tính năng Donation?
Khi cần gắn một nút "Ủng hộ tôi một ly cà phê" hay xây dựng trang quyên góp trên Drupal 10/11, phản xạ tự nhiên của nhiều developer là gõ lệnh: composer require drupal/commerce.
Drupal Commerce là một cỗ máy tuyệt vời. Nhưng trong project gần đây của mình, tôi đã quyết định dừng lại và tự viết một module riêng mang tên Simple Stripe Donation. Dưới đây là những quyết định kiến trúc đằng sau lựa chọn đó.
1. Domain Problem vs. Domain Model
Vấn đề cốt lõi không phải là Drupal Commerce "làm chậm request" hay "quá nặng", mà là: Drupal Commerce đưa vào một domain model và ecosystem lớn hơn nhiều so với domain problem cần giải quyết.
Nếu domain của bài toán chỉ đơn giản là:
Donation → Payment → Confirmation
Thì việc kéo theo bộ khung abstraction đồ sộ bao gồm:
Store → Order → Order Item → Cart → Customer Profile → Payment Gateway → Payment
sẽ tạo ra sự phức tạp không cần thiết (accidental complexity).
Việc duy trì cấu trúc dữ liệu khổng lồ này cho một tác vụ thanh toán một lần (one-time payment) làm tăng chi phí bảo trì hệ thống và overhead khi query dữ liệu.
2. Right Tool for the Right Domain
Tôi không có ý định chứng minh "Drupal Commerce tệ". Ngược lại, nó tỏa sáng khi bạn thực sự có nhu cầu về "Commerce". Quyết định kiến trúc luôn nằm ở việc chọn đúng công cụ cho đúng bài toán:
| Use case | Giải pháp phù hợp |
|---|---|
| E-commerce đầy đủ | Drupal Commerce |
| Product catalog & Inventory | Drupal Commerce |
| Cart + Order fulfillment | Drupal Commerce |
| Subscription / Complex Payment | Drupal Commerce (hoặc nền tảng tương đương) |
| Một lần donation | Simple Stripe Donation |
| "Buy me a coffee" | Simple Stripe Donation |
3. Nguyên tắc: Let Stripe own the payment UI; let Drupal own the business integration
Trước đây, chúng ta thường cố gắng render UI nhập thẻ ngay trên website để giữ chân người dùng. Nhưng điều đó đồng nghĩa với việc bạn phải gánh chịu rủi ro về PCI DSS, xử lý responsive UI cho hàng loạt phương thức mới (Apple Pay, Google Pay).
Với kiến trúc tích hợp qua Stripe Hosted Checkout, tôi loại bỏ hoàn toàn trách nhiệm đó:
Drupal (Create Checkout Session)
│
▼
Stripe Checkout (User submits payment)
│
▼
Stripe Server (Process & trigger Webhook)
│
▼
Drupal (Handle Webhook)
Tôi không cần phải sở hữu phần UI thanh toán. Thông tin thẻ không hề chạm vào máy chủ ứng dụng. Nhiệm vụ của hệ thống backend Drupal bây giờ chỉ tập trung vào một thứ duy nhất: Xử lý integration thật tốt.
4. Kiến trúc Webhook: Trái tim của hệ thống thanh toán
Trong hệ thống thanh toán bất đồng bộ, webhook handling chính là nơi thể hiện năng lực kiến trúc. Đừng bao giờ tin tưởng tuyệt đối vào payload gửi đến mà không có kiểm chứng.
Luồng xử lý webhook trong module của tôi được thiết kế chặt chẽ như sau:
Stripe Webhook
│
▼
Verify Signature (Ngăn chặn giả mạo request)
│
▼
Extract Event ID / Payment Intent ID
│
▼
Check Existing Record (Database lookup)
│
┌────┴────┐
│ │
Exists Not exists
│ │
200 Process
│
▼
Persist State (DB Transaction / Unique Constraints)
│
▼
Dispatch Event (Cho phép các module khác hook vào)
Để giải quyết triệt để bài toán Idempotency (Stripe có thể retry webhook nhiều lần do network lag), tôi không chỉ check bằng code PHP thuần túy, mà kết hợp thiết kế schema database với các ràng buộc duy nhất (Unique Constraints) trên trường session_id. Đồng thời, việc wrap quá trình lưu trữ trong DB Transaction đảm bảo không có state lấp lửng (partial save) nào xảy ra.
5. Tạm kết
Đôi khi, việc viết một đoạn code mới không phải để hệ thống làm được nhiều việc hơn, mà để ngăn hệ thống khỏi việc phải mang vác những thứ không thuộc về domain của nó.
⚙️ Implementation Để xem cách các khái niệm Webhook, Idempotency và Event Dispatcher được hiện thực hóa bằng code, bạn có thể tham khảo trực tiếp source code và case study thực tế của module tại: Simple Stripe Donation: Giải pháp thanh toán tinh gọn cho Drupal 10 & 11.