Answer-first: Cửa hàng Magento 2 của bạn có đang ngốn $125,000–$200,000/năm cho phí bản quyền Enterprise không? Thay vì đập đi xây lại (Big Bang rewrite), xu hướng 2026 là áp dụng mô hình Modular Monolith kết hợp Strangler Fig, từ từ bóc tách monolith thành các microservices độc lập sử dụng Go 1.25, Kratos v2, và Dapr PubSub.
Chào mừng bạn đến với cẩm nang toàn tập về Chuyển đổi sang Composable Commerce (Thương mại lắp ghép) — cách phẫu thuật tháo dỡ một khối monolith Magento 2 thành một nền tảng microservices chuẩn production, không làm rơi rớt một đơn hàng nào trong quá trình chuyển đổi, sẵn sàng cho xu hướng Agentic Commerce (thương mại được tối ưu hóa cho cả người dùng và AI agent).
Về Series này (E-E-A-T & Thực tiễn)
Nội dung này được đúc kết từ quá trình xây dựng một Nền tảng Composable Commerce thực tế — 21 Go microservices + 2 frontend đảm nhiệm toàn bộ quy trình nghiệp vụ thương mại: Duyệt (Browse) → Tìm kiếm (Search) → Giỏ hàng (Cart) → Thanh toán (Checkout) → Trả tiền (Pay) → Hoàn tất (Fulfill) → Vận chuyển (Ship) → Hoàn hàng (Return). Với hơn 17 năm kinh nghiệm xây dựng e-commerce, tác giả Lê Tuấn Anh đem đến cẩm nang thực chiến, loại bỏ 0 đồng phí bản quyền Magento. Mọi quyết định kiến trúc trong series này đều được đúc kết từ một trong 24 Hồ sơ Quyết định Kiến trúc (ADRs) của chúng tôi.
🎯 Tư vấn Chuyển đổi#
Đội ngũ của bạn đang lên kế hoạch thoát khỏi Magento hay đang đánh giá việc chuyển đổi sang kiến trúc composable commerce khi các hệ thống AI đang tái định hình e-commerce năm 2026?
👉 Đặt lịch Tư vấn Kiến trúc 1:1 với Senior Architect Lê Tuấn Anh — Hơn 17 năm kinh nghiệm xây dựng các nền tảng e-commerce enterprise tại Việt Nam và Đông Nam Á.
📚 Chương trình Cốt lõi#
Lược đồ EAV, khóa chính dạng số nguyên (integer primary keys), và sự phụ thuộc module PHP của Magento làm cho việc chuyển đổi trở nên đặc biệt hiểm nghèo. Series này mang đến cho bạn cẩm nang Strangler Fig 3 giai đoạn hoàn chỉnh:
Phần 0: Tóm tắt cho Quản lý — Tại sao $200K/Năm lại là một Cái Bẫy
Chi phí thực sự của Magento Enterprise, và tại sao kiến trúc composable lại tự hoàn vốn ngay trong Năm 1, cũng như giúp bạn tránh cạm bẫy “Distributed Monolith”.
Phần 1: Bounded Contexts trong DDD — Phân rã các Module Magento
Cách ánh xạ cấu trúc module của Magento thành 21 bounded context sử dụng Domain-Driven Design.
Phần 2: Rush Monorepo — Quản lý 21 Go Services + 2 Frontends
Tại sao chúng tôi chọn Microsoft Rush thay vì Nx/Turborepo cho một monorepo trộn lẫn Go + Next.js + React.
Phần 3: Golang + Kratos v2 — Đi sâu vào Framework Microservice
Kratos v2 xử lý transport, tiêm phụ thuộc (dependency injection), và mô hình common library.
Phần 4: Kiến trúc gRPC Internal + REST Gateway
Giao tiếp service-to-service bằng gRPC, REST qua gRPC-Gateway.
Phần 5: Chuyển đổi Lược đồ EAV — Cạm bẫy Lớn nhất của Magento
Gỡ rối catalog_product_entity_varchar, ánh xạ định danh integer → UUID.
Phần 6: Giai đoạn 1 — Strangler Fig: Chuyển đổi Read-Only + CDC
Triển khai Go service dưới dạng read-only, sử dụng CDC từ Magento MySQL.
Phần 7: Giai đoạn 2 — Dual-Write: Dapr PubSub + Feature Flags
Kích hoạt write APIs, đồng bộ qua Dapr PubSub + Transactional Outbox.
Phần 8: Giai đoạn 3 — Chuyển đổi Hoàn toàn: Zero Downtime + GitOps
Chuyển dịch traffic tăng dần, Magento về hot-standby.
Phần 9: Transactional Outbox + Saga Pattern Giữa các Service
Cách luồng saga Checkout → Order → Payment → Warehouse vận hành.
Phần 10: Điểm lại các ADR — Giải thích 24 Quyết định Kiến trúc
Mọi quyết định lớn — Dapr vs Kafka, database-per-service, gRPC vs REST.
🆚 Nền tảng này Thay thế cho cái gì#
| Tính năng | Magento Enterprise | Nền tảng này (2026 Standard) |
|---|
| Chi phí bản quyền | $125,000–$200,000/năm | $0 |
| Thanh toán VNPay / MoMo | Dùng plugin bên thứ ba | Tích hợp gốc, có circuit breaker |
| Khả năng chịu tải Flash sale | Scale toàn bộ monolith gấp 10 lần | Chỉ scale riêng Order + Payment |
| Agentic AI & LLMs | Khó tích hợp, schema phức tạp | API-first, Citation-ready cho AI |
| Quyền sở hữu dữ liệu | Vendor-hosted (bị phụ thuộc) | Tự host, kiểm soát toàn diện 100% |
🧭 Bạn Nên Bắt đầu Từ đâu?#
Các Câu Hỏi Thường Gặp (FAQ)#
Series này có mặc định rằng tôi đang chạy Magento 2 không?Đúng vậy. Các hướng dẫn chuyển đổi này nhắm tới Magento 2.x. Lược đồ EAV, primary keys dạng integer, và mô hình phụ thuộc module đều là các điểm đặc thù của Magento 2. Nếu bạn đang ở trên Magento 1, các mô hình DDD và Golang vẫn có thể áp dụng nhưng các câu truy vấn trích xuất SQL sẽ khác đi.
Nền tảng này sử dụng phiên bản Golang và framework nào?Nền tảng Composable Commerce chạy trên Go 1.25 với Kratos v2 (go-kratos). Cả 21 service chia sẻ chung một thư viện common nhằm tiêu chuẩn hóa các tác vụ outbox, idempotency, health checks, và quản lý cấu hình.
Quá trình chuyển đổi có thể thực hiện mà không cần ngắt hệ thống (zero downtime) không?Có. Phương pháp tiếp cận Strangler Fig 3 giai đoạn được thiết kế chuyên biệt cho zero downtime. Giai đoạn 1 chỉ điều hướng luồng dữ liệu đọc (reads) sang microservices; luồng ghi (writes) vẫn đi vào Magento. Giai đoạn 2 đưa vào chế độ dual-write kèm feature flags. Giai đoạn 3 chuyển dịch dần traffic.
Answer-first: Khởi đầu bằng tư duy Modular Monolith và sau đó dần dịch chuyển sang Composable Commerce (Thương mại lắp ghép) bằng 21 Go microservices, Kratos v2, và Dapr PubSub. Đây là lời giải triệt để cho bài toán thay thế Magento Enterprise. Nó mang lại năng lực thương mại cực cao (đa kho, saga thanh toán, tìm kiếm thời gian thực) với chi phí bản quyền bằng 0, giải quyết cả yêu cầu API-first cho Agentic Commerce trong hệ sinh thái AI (2026).
...
Answer-first: Số lượng service bạn cần được quyết định bởi cấu trúc đội ngũ, đặc tả chịu tải (scaling profile), và ranh giới của các bất biến nghiệp vụ (business invariants) của bạn — chứ không phải bởi các khuôn mẫu sáo rỗng. Trong môi trường e-commerce năm 2026, với việc chuyển dịch sang Agentic Commerce và Composable APIs, việc thiết lập ranh giới rõ ràng càng trở nên cốt lõi. Nền tảng trong series này sử dụng 21 services để đáp ứng 10,000+ đơn hàng/ngày.
...
Góc nhìn thực chiến (E-E-A-T): Quản trị code cho một hệ thống phân tán là bài toán đau đầu nhất mà tôi từng đối mặt trong các dự án di dời (migration) quy mô lớn. Với tư cách là người đã thiết lập kiến trúc CI/CD cho các team frontend và backend chạy song song trong suốt năm 2026, tôi khẳng định rằng việc chọn sai công cụ monorepo ở giai đoạn đầu sẽ khiến dự án trả giá đắt bằng hàng trăm giờ gỡ lỗi phantom dependencies.
...
Góc nhìn thực chiến (E-E-A-T): Trải qua nhiều dự án đập đi xây lại từ PHP nguyên khối sang Go, tôi nhận thấy sự tự do quá trớn trong Go thường là con dao hai lưỡi. Việc ép toàn bộ đội ngũ kỹ sư tuân thủ khuôn khổ 5 lớp nghiêm ngặt của Kratos v3 trong suốt giai đoạn 2026 đã cứu vớt dự án khỏi cảnh “code rác” lan tràn. Những gì trình bày dưới đây là bản thiết kế đã được tôi tinh chỉnh và chứng minh hiệu quả trên môi trường production với hàng ngàn RPS.
...
Mọi API hướng ra công chúng (public-facing) trong Nền tảng Composable Commerce đều bắt đầu từ một file .proto. Phần code — bao gồm các hàm handler gRPC viết bằng Go, TypeScript SDK, các route HTTP, kiểm tra tính hợp lệ của request (request validation), các mã lỗi — tất cả đều được tự động generate ra từ bản hợp đồng (contract) đó. Bài viết này sẽ ghi chép lại những quy ước đằng sau để hệ thống đó vận hành mượt mà.
...
Cấu trúc EAV schema chính là lý do khiến phần lớn các dự án chuyển đổi khỏi Magento chuốc lấy thất bại.
Nhìn từ bên ngoài, nó có vẻ dễ xơi: dữ liệu của sản phẩm bị băm ra rải rác ở catalog_product_entity, catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, catalog_product_entity_datetime, và catalog_product_entity_text. Sáu cái bảng, viết một cái job ETL đơn giản, làm một cuối tuần là xong.
Nhưng rồi bạn phát hiện ra rằng attribute_id = 75 mang ý nghĩa “tên sản phẩm” (product name) trong cái database của bạn, nhưng nó lại mang nghĩa “màu sắc” (color) trong cái database trên môi trường staging. Mỗi một mã ID thuộc tính (attribute ID) được sinh ra tự động ngay tại thời điểm cài đặt (install time) và nó hoàn toàn khác biệt giữa các môi trường với nhau. Bất kỳ script ETL nào dám cả gan gán cứng (hardcode) các mã attribute ID này sẽ lập tức đẻ ra một đống dữ liệu rác bẹp dí (corrupted data) khi mang lên chạy ở production.
...
Giai đoạn 1 (Phase 1) là giai đoạn an toàn nhất trong toàn bộ cuộc di dời — đó là chủ ý thiết kế (by design). Sẽ không có bất kỳ thao tác ghi (write) dữ liệu nào chạm tới hệ thống microservice mới. Magento vẫn là nguồn sự thật duy nhất (source of truth) cho mọi sửa đổi dữ liệu. Việc duy nhất mà Giai đoạn 1 làm, đó là chứng minh rằng đống microservice của bạn có thể phục vụ các thao tác đọc (read) với tốc độ nhanh hơn và độ ổn định cao hơn Magento.
...
Ở Giai đoạn 1, cả hai hệ thống đều tồn tại song song nhưng chỉ có duy nhất một thằng được phép ghi dữ liệu: Magento. Sang Giai đoạn 2, cả hai hệ thống sẽ cùng thi nhau ghi dữ liệu cùng một lúc (simultaneously). Đây là giai đoạn phức tạp nhất về mặt kỹ thuật — và cũng là nơi mà phần lớn các dự án di dời tự tay làm hỏng (corrupt) dữ liệu của chính mình nếu họ không chuẩn bị sẵn một chiến lược phân xử xung đột (conflict resolution strategy) rõ ràng sòng phẳng.
...
Giai đoạn 3 (Phase 3) là hồi kết: 100% traffic chuyển hẳn sang hệ thống microservice, Magento chính thức lùi về làm một kho lưu trữ thụ động (passive archive), và toàn bộ nền tảng vận hành hoàn toàn trên các microservice Go thông qua quy trình GitOps. Sẽ không còn bóng dáng của PHP trong những luồng request quan trọng nữa. Và cũng chấm dứt luôn chuỗi ngày phải chi trả chi phí gia hạn giấy phép (license) cho Magento.
...
Khi một khách hàng bấm nút đặt hàng trên nền tảng Composable Commerce, có tới 7 sự kiện bắt buộc phải diễn ra theo chuỗi vắt ngang qua 4 service hoàn toàn độc lập: Tạo Đơn hàng (Order created) → Duyệt Thanh toán (Payment authorized) → Giữ chỗ Tồn kho (Stock reserved) → Kích hoạt Giao nhận (Fulfillment triggered) → Bắn Thông báo (Notification sent) → Cộng Điểm thưởng (Loyalty points awarded) → Tạo Mã vận đơn (Shipping label generated). Bất kỳ mắc xích nào trong số này cũng có thể đứt. Mạng có thể rớt. Database có thể sập. Một cái cổng thanh toán (payment gateway) của bên thứ ba có thể bị timeout.
...
Góc nhìn thực chiến (E-E-A-T): Với tư cách là Kiến trúc sư Giải pháp trực tiếp dẫn dắt quá trình di dời (migration) các nền tảng thương mại điện tử lớn trong giai đoạn 2026, tôi đã đúc kết và chuẩn hóa các mẫu thiết kế (design patterns) này. Các quyết định bên dưới không phải là lý thuyết suông, mà là kết quả đẫm máu từ hàng chục lần “sập hệ thống” và tối ưu hóa hệ thống để chịu tải hàng triệu request mỗi ngày.
...