Báo cáo dễ hiểu về quyết định kiến trúc OPSKOO Global

Ngày lập: 2026-05-30

Bản này là phiên bản dễ hiểu của báo cáo:

bao-cao-quyet-dinh-kien-truc-toan-he-thong-opskoo-global.md

Mục tiêu của bản này không phải trình bày thật nhiều thuật ngữ, mà là giúp trả lời rõ:

• OPSKOO thực sự là hệ thống gì?
• Vì sao nó khó?
• Nên chọn kiến trúc nào?
• Vì sao nên dùng .NET thay vì Django cho dự án mới này?
• Những thứ nào nên làm sớm, thứ nào chưa nên làm?
• Nếu làm sai thì dễ chết ở đâu?

1. Kết luận ngắn nhất

Nếu OPSKOO là dự án mới, làm API-first, không phụ thuộc Django Admin, có AI agent hỗ trợ code, và mục tiêu dài hạn là sàn giáo dục global, tôi khuyên:

Dùng ASP.NET Core.

Xây theo modular monolith.

Database chính dùng PostgreSQL.

Frontend dùng Next.js.

Payment dùng provider như Stripe/Adyen/PayPal/VNPAY/MoMo tùy thị trường.

Live class ban đầu dùng Zoom/Google Meet/link ngoài.

AI ban đầu chỉ hỗ trợ con người, chưa cho AI tự quyết định việc quan trọng.

Không làm microservices ngay từ đầu.

Không tự build video platform, payment gateway, escrow thật, social feed lớn ngay từ đầu.

Nói dễ hiểu hơn:

Hãy xây OPSKOO như một tòa nhà lớn có nhiều khu rõ ràng,

không xây thành một đống phòng lộn xộn,

cũng chưa cần xây thành 20 tòa nhà riêng ngay từ đầu.

2. OPSKOO không phải chỉ là web bán khóa học

Nếu OPSKOO chỉ là:

Đăng khóa học -> học viên mua -> xem bài học

thì Django, Laravel, Rails, NestJS hay .NET đều làm được.

Nhưng OPSKOO thực tế không đơn giản như vậy.

OPSKOO đang muốn là:

Sàn giáo dục + hồ sơ giáo viên/trung tâm + đánh giá uy tín

+ đặt lịch/học thử + thanh toán + đảm bảo giao dịch

+ LMS + CRM + vận hành trung tâm + AI + dữ liệu + global.

Nó giống một hệ thống ghép từ nhiều hệ nhỏ:

Vì vậy nếu nghĩ OPSKOO là “web bán khóa học”, kiến trúc sẽ bị nhỏ quá.

Nhưng nếu nghĩ OPSKOO là “siêu hệ thống global đầy đủ ngay”, kiến trúc sẽ bị to quá.

Điểm đúng là:

Xây lõi đủ nghiêm túc để không sập sau này,

nhưng MVP vẫn phải đủ gọn để ra thị trường nhanh.

3. Vì sao tôi nghiêng về .NET thay vì Django?

Không phải vì Django tệ.

Django rất tốt nếu:

• cần admin nhanh,
• team đã mạnh Python/Django,
• hệ thống chủ yếu là CRUD,
• backend không quá nhiều domain phức tạp,
• cần ra sản phẩm quản trị nội bộ rất nhanh.

Nhưng với OPSKOO mới từ đầu, điểm mạnh nhất của Django là Django Admin lại không còn quá quan trọng. Bạn đã nói rõ: thời đại AI agent, vấn đề không phải bạn có học .NET được hay không, và bạn không cần Django Admin.

Khi bỏ Django Admin ra khỏi bài toán, ta phải nhìn lại:

Stack nào giúp kiểm soát hệ thống phức tạp tốt hơn trong dài hạn?

Tôi chọn ASP.NET Core vì:

• C# có kiểu dữ liệu rõ, compiler bắt lỗi sớm.
• Khi AI agent viết code, type system giúp chặn nhiều lỗi ngu ngơ hơn Python động.
• .NET hợp với domain lớn, business logic nhiều, module rõ, service layer rõ.
• ASP.NET Core có sẵn nền tốt cho API, auth, middleware, background job, dependency injection, testing.
• Project boundary trong .NET dễ ép module không dính chéo nhau hơn Django apps nếu team có kỷ luật.

Nói dễ hiểu:

Django giúp đi nhanh khi cần admin và CRUD.

.NET giúp giữ trật tự tốt hơn khi hệ thống lớn, nhiều luật, nhiều trạng thái, nhiều tiền, nhiều quyền truy cập.

Với OPSKOO, thứ đáng sợ không phải là render một trang khóa học.

Thứ đáng sợ là:

• học viên đã trả tiền nhưng không được quyền học,
• giáo viên nhận tiền sai,
• refund sai,
• review giả,
• trung tâm thấy dữ liệu của trung tâm khác,
• học viên bị mất tiến độ học,
• AI chấm/sửa/đề xuất sai nhưng hệ thống vẫn tin,
• payment webhook chạy 2 lần tạo double order,
• code ban đầu quá lộn xộn nên sau này không tách nổi.

Những lỗi đó cần architecture chặt hơn là admin nhanh.

4. Modular monolith là gì?

Đây là điểm quan trọng nhất.

Monolith nghĩa là:

Một ứng dụng backend chính.

Deploy một khối chính.

Chung một database chính.

Modular nghĩa là:

Bên trong vẫn chia khu rất rõ.

Identity là Identity.

Payment là Payment.

LMS là LMS.

CRM là CRM.

AI là AI.

Search là Search.

Không module nào tự tiện chọc lung tung vào ruột module khác.

Vậy modular monolith nghĩa là:

Bên ngoài nhìn như một hệ thống gọn.

Bên trong chia ranh giới như một hệ thống lớn nghiêm túc.

Nó khác với code lộn xộn.

Code lộn xộn là:

View gọi thẳng database.

Payment sửa enrollment.

LMS tự kiểm tra order.

CRM tự tính quyền học.

AI tự ghi điểm chính thức.

Không ai biết trạng thái thật nằm ở đâu.

Modular monolith đúng phải là:

Order quyết định đơn hàng.

Payment ghi nhận thanh toán.

Ledger ghi dòng tiền.

Entitlement quyết định quyền học.

LMS chỉ hỏi quyền học, không tự đoán.

Trust quyết định xác minh/review.

AI chỉ đề xuất, con người hoặc workflow duyệt.

5. Vì sao không microservices ngay?

Microservices nghe rất “global” và “pro”, nhưng với OPSKOO giai đoạn đầu thì nguy hiểm.

Nếu tách sớm thành nhiều service:

Identity service

Course service

Payment service

LMS service

CRM service

AI service

Notification service

Search service

thì bạn sẽ phải giải quyết thêm:

• service gọi nhau lỗi thì sao,
• dữ liệu lệch nhau thì sao,
• transaction qua nhiều service thế nào,
• deploy service A có làm hỏng service B không,
• log nằm rải rác ở đâu,
• debug một đơn hàng lỗi đi qua 5 service thế nào,
• version API nội bộ ra sao,
• local dev chạy 8 service thế nào.

Trong khi MVP còn chưa chắc provider có dùng thật không.

Vì vậy microservices ngay từ đầu là quá đắt.

Nên làm:

Modular monolith trước.

Khi module nào thật sự đau, thật sự có traffic, thật sự cần scale riêng,

lúc đó mới tách thành service.

Ví dụ sau này có thể tách:

• Search,
• Notification,
• Media processing,
• AI workflow,
• Payment reconciliation,
• Analytics pipeline.

Nhưng không nên tách ngay khi chưa có dữ liệu thật.

6. OPSKOO dễ chết ở đâu nhất?

6.1. Chết vì lẫn lộn Course, Class, Enrollment và Entitlement

Đây là lỗi rất phổ biến.

Cần phân biệt:

Nếu trộn hết vào một bảng Course, sau này sẽ rất rối.

Ví dụ:

• Một khóa IELTS có nhiều lịch khai giảng.
• Một giáo viên có nhiều lớp.
• Một học viên mua gói học thử.
• Một học viên được refund một phần.
• Một trung tâm bán cùng khóa học với nhiều mức giá.

Nếu model sai, càng code càng đau.

6.2. Chết vì payment nhìn đơn giản nhưng thật ra rất khó

Payment không chỉ là:

User bấm trả tiền -> thành công -> mở khóa học.

Thực tế có:

• pending,
• success,
• failed,
• expired,
• refunded,
• partial refund,
• chargeback,
• duplicate webhook,
• payment thành công nhưng app chưa nhận,
• app nhận webhook 2 lần,
• học viên trả tiền nhầm,
• giáo viên yêu cầu rút tiền,
• nền tảng giữ phí,
• tranh chấp.

Vì vậy phải có:

• order state machine,
• payment transaction,
• ledger,
• idempotency,
• webhook log,
• reconciliation,
• refund/dispute workflow.

Nói dễ hiểu:

Đừng chỉ lưu "paid = true".

Hãy lưu bằng chứng tiền đi như thế nào.

6.3. Chết vì gọi "escrow" quá sớm

CEO có nói Payment & Escrow.

Nhưng “escrow” là từ nhạy cảm. Ở nhiều thị trường, escrow liên quan pháp lý/tài chính.

MVP nên gọi mềm hơn:

payment hold

guarantee window

provider payout after confirmation

refund/dispute policy

Chỉ gọi là escrow thật khi:

• payment provider hỗ trợ,
• pháp lý rõ,
• điều khoản rõ,
• quy trình dispute/refund rõ,
• kế toán/thuế rõ.

6.4. Chết vì Trust Score bị game

Trust score nghe hay, nhưng rất dễ bị thao túng.

Ví dụ:

• review giả,
• học viên ảo,
• giáo viên tự mua khóa của mình,
• trung tâm ép học viên review tốt,
• đối thủ review xấu,
• profile đẹp nhưng chất lượng thật kém.

MVP không nên làm điểm trust quá thông minh.

Nên làm trước:

• verified/unverified,
• giấy tờ đã duyệt,
• chứng chỉ đã duyệt,
• review chỉ từ học viên đã học/mua thật,
• lịch sử phản hồi,
• số lớp đã hoàn thành,
• khiếu nại/refund rate.

Trust nên bắt đầu bằng bằng chứng thật, chưa cần công thức AI đẹp.

6.5. Chết vì LMS biến thành sản phẩm quá lớn

LMS có thể rất rộng:

• bài học,
• tài liệu,
• video,
• live class,
• homework,
• quiz,
• exam,
• gradebook,
• certificate,
• progress,
• discussion,
• SCORM/xAPI/LTI,
• parent portal,
• mobile offline.

Nếu làm hết sớm, MVP sẽ chết.

MVP nên làm LMS đủ dùng:

• lớp,
• buổi học,
• tài liệu,
• bài tập,
• nộp bài,
• chấm/nhận xét thủ công,
• tiến độ cơ bản,
• link live class ngoài.

Chưa nên tự build:

• video streaming riêng,
• live classroom riêng,
• exam proctoring,
• adaptive learning phức tạp,
• SCORM player đầy đủ,
• gradebook quá phức tạp.

6.6. Chết vì tenant/data leak

OPSKOO có giáo viên, trung tâm, học viên, ops admin.

Nếu sau này một trung tâm thấy dữ liệu của trung tâm khác, niềm tin sẽ sập.

Vì vậy phải thiết kế tenant từ đầu:

• user thuộc tổ chức nào,
• vai trò trong tổ chức là gì,
• dữ liệu nào thuộc tenant nào,
• admin OPSKOO được xem gì,
• support access có audit không,
• query nào bắt buộc filter theo tenant.

Đây là thứ phải làm sớm, không nên vá muộn.

6.7. Chết vì AI được quyền quá lớn

AI rất hữu ích, nhưng giai đoạn đầu nên dùng AI để:

• format tài liệu,
• tạo outline bài học,
• gợi ý bài tập,
• tóm tắt phản hồi,
• phân loại support ticket,
• gợi ý nội dung profile,
• hỗ trợ ops tìm bất thường.

Không nên cho AI tự động:

• chấm điểm chính thức,
• quyết định refund,
• khóa tài khoản giáo viên,
• xác minh giấy tờ cuối cùng,
• thay đổi quyền học,
• chuyển tiền,
• tạo cam kết học tập với học viên.

Nguyên tắc:

AI đề xuất.

Hệ thống ghi log.

Con người hoặc workflow kiểm soát quyết định quan trọng.

7. Kiến trúc đề xuất nhìn theo sơ đồ dễ hiểu

Web/App

|

v

Next.js Frontend

|

v

ASP.NET Core API - Modular Monolith

|

|-- Identity & Access

|-- Tenant & Organization

|-- Provider Profile & Trust

|-- Catalog & Offering

|-- Search & Discovery

|-- Booking & Order

|-- Payment & Ledger

|-- Entitlement

|-- LMS

|-- CRM/Ops

|-- Notification

|-- AI Workflow

|

v

PostgreSQL

Ngoài hệ thống chính:

Object Storage + CDN -> tài liệu, ảnh, file, video upload

Payment Provider -> thanh toán, refund, payout

Email/SMS/Push Provider -> thông báo

Zoom/Google Meet -> live class MVP

Analytics/Warehouse -> báo cáo sau này

AI Provider -> LLM, OCR, content assistant

Điểm quan trọng:

Core truth nằm trong OPSKOO.

Những thứ khó và đắt thì dùng provider trước.

Không nên tự build quá sớm:

• payment gateway,
• live streaming,
• DRM,
• email infrastructure,
• AI model riêng,
• search engine phức tạp,
• BI platform phức tạp.

8. Nên chia module thế nào?

8.1. Identity & Access

Trả lời:

Ai đang đăng nhập?

Người đó có vai trò gì?

Người đó được làm gì?

Ví dụ:

• learner,
• teacher,
• center owner,
• center staff,
• OPSKOO support,
• OPSKOO admin.

Quan trọng:

• không chỉ có is_admin,
• cần role theo tổ chức,
• cần audit khi admin can thiệp dữ liệu.

8.2. Tenant & Organization

Trả lời:

Dữ liệu này thuộc giáo viên/trung tâm nào?

Ai trong tổ chức được xem/sửa?

OPSKOO không chỉ có user cá nhân. Có trung tâm, nhân viên, giáo viên thuộc trung tâm, cộng tác viên.

8.3. Provider Profile & Trust

Trả lời:

Hồ sơ giáo viên/trung tâm có đáng tin không?

Bằng chứng nào chứng minh điều đó?

Review có thật không?

Không nên bắt đầu bằng trust score quá phức tạp.

Nên bắt đầu bằng:

• hồ sơ,
• chứng chỉ,
• xác minh thủ công,
• badge,
• review từ giao dịch thật,
• lịch sử lớp/giao dịch.

8.4. Catalog & Offering

Trả lời:

Đang bán cái gì?

Bán với giá nào?

Ai dạy?

Lịch nào?

Điều kiện gì?

Đây là module rất quan trọng vì education marketplace không giống bán áo/quần.

Khóa học có:

• cấp độ,
• mục tiêu,
• lịch học,
• hình thức học,
• giáo viên,
• số buổi,
• học thử,
• cam kết,
• đầu ra,
• tài liệu,
• độ tuổi,
• điều kiện đầu vào.

8.5. Search & Discovery

Trả lời:

Học viên tìm thấy ai/khóa nào?

Vì sao kết quả đó đứng trên?

MVP nên dùng:

• PostgreSQL full-text search,
• filter theo môn/kỹ năng/giá/lịch/location/online/offline,
• sort cơ bản,
• scoring đơn giản.

Chưa cần ngay:

• vector search phức tạp,
• AI matching quá thông minh,
• ranking kiểu mạng xã hội.

Lý do:

Chưa có dữ liệu đủ tốt thì AI matching cũng chỉ là trang trí.

8.6. Booking, Order & Entitlement

Đây là xương sống của marketplace.

Trả lời:

Học viên đã đặt gì?

Đơn hàng ở trạng thái nào?

Đã thanh toán chưa?

Sau thanh toán được quyền học gì?

Nguyên tắc:

Không mở quyền học trực tiếp từ payment callback.

Payment thành công -> Order cập nhật -> Entitlement được cấp -> LMS cho vào học.

Làm vậy để tránh rối khi refund, dispute, hủy lớp, đổi lớp.

8.7. Payment & Ledger

Trả lời:

Tiền vào đâu?

Tiền ra đâu?

Nền tảng giữ phí bao nhiêu?

Refund thế nào?

Provider nhận bao nhiêu?

Nguyên tắc:

Payment là sự kiện thanh toán.

Ledger là sổ cái ghi dòng tiền.

Order là đơn hàng.

Ba cái này không nên trộn làm một.

8.8. LMS

Trả lời:

Học viên học lớp nào?

Buổi nào?

Tài liệu nào?

Bài tập nào?

Tiến độ ra sao?

MVP LMS nên đủ để provider vận hành lớp sau khi bán được học viên.

Không cần cạnh tranh ngay với Moodle/Open edX.

8.9. CRM/Ops

Trả lời:

Lead đang ở đâu?

Ai cần chăm sóc?

Trial nào sắp diễn ra?

Học viên nào có nguy cơ bỏ?

Provider nào đang gặp vấn đề?

Đây là phần rất quan trọng vì OPSKOO không chỉ là phần mềm, mà còn là vận hành marketplace.

8.10. AI Workflow

Trả lời:

AI được làm gì?

Kết quả AI ai duyệt?

AI dùng dữ liệu nào?

Có log không?

Có rollback không?

AI nên được thiết kế như một workflow có kiểm soát, không phải một ô chat được gắn vào mọi nơi.

9. Nên làm gì trong MVP?

MVP không nên cố làm “OPSKOO hoàn chỉnh”.

MVP nên chứng minh:

Giáo viên/trung tâm có sẵn sàng dùng OPSKOO để có thêm học viên không?

Học viên có tin và đặt học qua OPSKOO không?

OPSKOO có xử lý được vòng giao dịch đầu tiên không?

Nên làm:

1. Provider onboarding. 2. Profile giáo viên/trung tâm. 3. Basic verification. 4. Course/offering/listing. 5. Search/filter. 6. Course/provider detail page. 7. Trial booking/enrollment request. 8. Order/payment basic. 9. Entitlement sau thanh toán. 10. LMS cơ bản: lớp, buổi, tài liệu, bài tập, nộp bài. 11. CRM lead đơn giản. 12. Ops admin xem provider, course, order, payment, dispute. 13. Notification email/SMS cơ bản. 14. AI format tài liệu/bài tập.

Chưa nên làm:

1. Social newsfeed lớn. 2. Native livestream. 3. Video streaming/DRM riêng. 4. Escrow thật nếu chưa có pháp lý/provider. 5. Trust score phức tạp. 6. AI matching phức tạp. 7. Microservices. 8. Multi-region active-active. 9. Mobile app native đầy đủ. 10. SCORM/xAPI/LTI đầy đủ ngay.

10. Roadmap dễ hiểu

Giai đoạn 0: Dựng móng

Mục tiêu:

Không code loạn từ ngày đầu.

Làm:

• ASP.NET Core solution structure.
• Modules rõ.
• PostgreSQL.
• Auth cơ bản.
• Tenant model.
• Audit log.
• CI/CD.
• Logging/monitoring cơ bản.
• Coding conventions cho AI agent.
• ADR để ghi quyết định kiến trúc.

Giai đoạn 1: Provider và Trust

Mục tiêu:

Giáo viên/trung tâm có hồ sơ đáng tin.

Làm:

• provider profile,
• center profile,
• teacher profile,
• upload giấy tờ/chứng chỉ,
• admin duyệt,
• badge verified/unverified,
• public profile page.

Giai đoạn 2: Discovery

Mục tiêu:

Học viên tìm được khóa học/người dạy phù hợp.

Làm:

• category,
• course/offering,
• listing,
• search,
• filter,
• sort,
• detail page.

Giai đoạn 3: Booking và Payment

Mục tiêu:

Học viên có thể đặt học/thanh toán và hệ thống ghi nhận đúng.

Làm:

• booking trial,
• order,
• payment provider,
• webhook idempotency,
• payment status,
• entitlement,
• refund/dispute basic.

Giai đoạn 4: LMS cơ bản

Mục tiêu:

Sau khi mua, học viên thật sự học được.

Làm:

• class/cohort,
• session,
• materials,
• homework,
• submission,
• manual grading/comment,
• progress.

Giai đoạn 5: CRM/Ops

Mục tiêu:

Provider và OPSKOO vận hành được.

Làm:

• lead pipeline,
• provider dashboard,
• ops dashboard,
• revenue/commission dashboard,
• issue/dispute dashboard.

Giai đoạn 6: AI có kiểm soát

Mục tiêu:

AI giúp tiết kiệm thời gian nhưng không phá hệ thống.

Làm:

• format tài liệu,
• tạo outline bài học,
• gợi ý bài tập,
• tóm tắt feedback,
• phân loại support,
• AI logs,
• human approval.

Giai đoạn 7: Scale thật

Mục tiêu:

Chỉ scale khi có dữ liệu chứng minh cần scale.

Có thể tách:

• search service,
• notification service,
• AI service,
• media processing,
• analytics pipeline,
• payment reconciliation.

11. Cách nghĩ đúng khi chọn kiến trúc

Đừng hỏi:

Django hay .NET cái nào xịn hơn?

Hãy hỏi:

Hệ thống này dễ hỏng ở đâu?

Lỗi nào làm mất tiền/mất niềm tin/mất dữ liệu?

State thật nằm ở đâu?

Ai được sửa state đó?

Có audit không?

Khi payment/refund/dispute xảy ra thì workflow thế nào?

Tenant có bị lộ dữ liệu chéo không?

AI có được quyền quá lớn không?

Sau này tách service có đường ra không?

Từ các câu hỏi đó, lựa chọn .NET modular monolith hợp lý hơn.

12. Nếu nói với CEO thì nói sao?

Có thể nói ngắn gọn:

OPSKOO không nên được xây như một website bán khóa học.

Nó là nền tảng giao dịch và vận hành giáo dục.

MVP vẫn phải ra nhanh, nhưng lõi phải thiết kế đúng:

ai bán, ai học, ai đã trả tiền, ai được quyền học,

tiền đi đâu, ai đáng tin, dữ liệu thuộc trung tâm nào.

Vì vậy ta chọn .NET modular monolith:

đủ nhanh cho MVP, đủ chặt cho hệ thống lớn,

và sau này có thể tách service khi có dữ liệu thật.

13. Quyết định cuối cùng

Tôi khuyên:

Chọn ASP.NET Core cho backend mới của OPSKOO.

Không chọn Django làm nền chính nếu không cần Django Admin.

Không làm microservices ngay.

Không build full LMS/social/video/payment/AI quá sớm.

Tập trung xây marketplace transaction loop thật chắc.

Vòng loop quan trọng nhất:

Provider onboard

-> profile/listing đủ tin

-> learner tìm thấy

-> booking/enroll

-> payment/order đúng

-> entitlement đúng

-> LMS học được

-> CRM/ops theo dõi được

-> dữ liệu quay lại cải thiện marketplace.

Nếu vòng này chạy tốt, OPSKOO có nền để lớn.

Nếu vòng này sai, mọi thứ còn lại như AI, social, global, livestream đều chỉ là trang trí.

14. Ghi chú nguồn

Bản dễ hiểu này được rút gọn từ báo cáo đầy đủ đã nghiên cứu các nguồn:

• Microsoft ASP.NET Core, EF Core, ASP.NET Core Identity.
• Martin Fowler về microservices và điều kiện để dùng microservices.
• AWS Well-Architected.
• 1EdTech LTI, OneRoster, QTI.
• ADL xAPI.
• Stripe Connect và các mô hình payment platform.
• PCI DSS.
• NIST AI Risk Management Framework.
• OWASP API Security, ASVS, LLM Top 10.
• WCAG 2.2.
• OpenTelemetry.
• Google SRE Book.
• DORA report.

Chi tiết nguồn và lập luận đầy đủ nằm trong:

bao-cao-quyet-dinh-kien-truc-toan-he-thong-opskoo-global.md