Early Bird 500K · giảm 50% đến 30/06/2026

Cài tư duy data modelingvào đầu backend fresher Việt Nam

Name: Design Data Model cho Business Domain
Price: 500000 VND
Availability: InStock

Bạn biết SQL. Biết 1NF/2NF/3NF. Nhận requirement thực vẫn ngồi nhìn màn hình 1 tiếng. Khoá này cài pattern matching vào đầu bạn: nhìn requirement → đoán archetype → schema ra trong 10 phút, không phải 1 tiếng.

Xem 10 archetype sân tập (30 giây)

Fresher vs Dev đi làm lâu · Cùng bài toán, schema khác biệt một trời một vực.

// The Reality Check

6 thứ trường không nói, sách không viết, production bắt bạn dùng

Lý thuyết không sai, chỉ dừng quá sớm. Đây là 6 khoảng trống bạn chỉ học được sau 2 năm đi làm. Hoặc trong khoá này.

Lý thuyết nói A, production làm B. B không sai. B là A + context bạn chưa từng có.

Lý thuyết

Trường nói: chuẩn hoá lên 3NF/BCNF là mục tiêu. Càng cao càng tốt.

Production thực tế

Production: hầu hết schema đều có chủ đích denormalize ở chỗ cần performance: counter cache, materialized view, embedded JSON. 3NF tuyệt đối = JOIN 8 bảng cho 1 query trang chủ = app chết. Dev đi làm lâu không 'phá rule', họ biết khi nào rule cản trở business.

Lý thuyết

Trường nói: UPDATE để thay đổi giá trị. SQL có UPDATE thì cứ dùng.

Production thực tế

Production: nhiều hệ thống KHÔNG UPDATE balance, KHÔNG UPDATE inventory, KHÔNG UPDATE lương employee. INSERT history/ledger entry. Lý do: audit, compliance, rollback, debug 'tại sao tháng trước số ra khác'.

Lý thuyết

Trường nói: foreign key đảm bảo integrity. Thêm FK vào mọi cột id.

Production thực tế

Production: ở scale lớn, nhiều team cố tình bỏ FK: write nhanh hơn, replicate dễ hơn, microservice tách boundary rõ hơn. Trade-off có chủ đích. Không phải junior bỏ vì lười.

Lý thuyết

Trường nói: ERD vẽ trên giấy. 1 entity = 1 bảng. Schema fixed sau khi vẽ xong.

Production thực tế

Production: requirement đổi mỗi sprint. Schema phải linh hoạt: EAV cho custom field, JSONB cho metadata, polymorphic cho 1 cột ref nhiều entity type. Pattern này hầu hết tutorial bỏ qua.

Lý thuyết

Trường nói: SQL JOIN/GROUP BY/subquery là chính. Index nhắc qua 1 slide.

Production thực tế

Production: index quyết định app sống hay chết. Query 30 giây → 0.3 giây chỉ vì 1 composite index đúng. Biết composite/partial/covering index = lương cộng 5tr/tháng. Không đùa.

Lý thuyết

Trường nói: 1 schema cho cả app. Multi-tenant? Có nhắc, không deep.

Production thực tế

Production: hầu hết SaaS VN (POS, HR, kế toán, e-commerce, CRM) là multi-tenant. Mọi bảng phải có tenant_id. Sai 1 query = data khách hàng A lộ sang khách hàng B = mất hợp đồng + lawsuit. Không có 'oops'.

Mình không bảo lý thuyết sai. Mình share phần production-context mà sách dừng lại quá sớm. Nền tảng lý thuyết bạn tự lo, nó vẫn cần.

4 tình huống bạn đang gặp, và bạn biết là đang gặp

Không vẽ drama. Đây là tình huống thật của fresher/junior backend VN. Nếu bạn dính 2/4, đọc tiếp. Dính 0/4 thì khoá này không cần thiết.

Biết SQL, không biết bắt đầu schema từ đâu

1NF/2NF/3NF thuộc. JOIN/GROUP BY/subquery viết được. Sếp giao 'design schema cho module HRM', ngồi 1 tiếng vẽ rồi xoá, vẽ rồi xoá. Không phải bạn dốt, là chưa có ai chỉ bạn khung tư duy đi từ requirement sang schema.

Đồng nghiệp lâu năm nói thuật ngữ bạn chưa từng nghe

Standup: 'cái này phải effective-date', 'thêm idempotency key đi', 'làm ledger entry hộ', 'EAV phần custom field', 'row-level security cho tenant'. Bạn google từng cái rồi quên. Vì google không cho bạn thấy chúng connect với nhau thành pattern.

Tưởng hệ thống nội bộ là CRUD

Nghĩ HRM/POS/Booking chỉ là CRUD vài bảng. Vào job mới: temporal pattern (lương đổi theo thời gian), ledger (không UPDATE tồn kho), EAV (custom field), multi-tenant (1 sai data leak khách hàng). Hệ thống nội bộ ở data model thường phức tạp HƠN TMĐT.

Phỏng vấn hỏi 'design schema cho X' → đứng hình

Round system design fresher VN luôn có: 'design schema cho phòng khám', 'cho ví điện tử', 'cho LMS'. Bạn vẽ 3 bảng rồi bí. Không phải bạn không nghĩ được, bạn chưa bao giờ học pattern matching từ requirement → archetype.

// Myth-Buster

Ngộ nhận đắt nhất của fresher VN: "Hệ thống nội bộ chỉ là CRUD"

Câu này 9/10 fresher nói trước khi đi làm. 2 tháng sau khi vào job, không ai nói nữa. Ở mức data model, hệ thống nội bộ thường phức tạp HƠN Big Tech, vì business rule chi tiết hơn, edge case nhiều hơn, compliance khắt khe hơn.

Big Tech VN (TMĐT lớn, ví điện tử, siêu app, ride-hailing) có pattern khá chuẩn vì domain đã được nghiên cứu hàng chục năm: e-commerce, payment, ride-hailing. Hệ thống nội bộ: mỗi công ty 1 kiểu, business logic vô lý theo cảm tính sếp, requirement đổi mỗi tuần. Schema phải linh hoạt gấp 3.

Ngộ nhận của fresher

"HRM chỉ là 1 bảng employees với vài cột."

Reality check

1 employee có lịch sử position, lịch sử salary, lịch sử department thay đổi theo thời gian. Phải temporal pattern (valid_from, valid_to). Schema sai 1 dòng = tính sai lương 6 tháng cho 200 người = sếp gọi 11h đêm.

Ngộ nhận của fresher

"Inventory chỉ cần cột quantity, UPDATE khi xuất nhập."

Reality check

Mọi WMS production dùng ledger pattern: INSERT stock_movement, KHÔNG UPDATE quantity. Lý do: audit (vì sao mất 5 cái?), multi-warehouse, oversell prevention, lot tracking. UPDATE quantity = production incident đang chờ ngày bùng.

Ngộ nhận của fresher

"Booking khám bệnh chỉ là CRUD lịch hẹn."

Reality check

Recurring availability (BS làm sáng T2-T6), exception (nghỉ lễ), double-booking prevention, buffer time giữa các ca, waitlist tự động fill khi cancel, group booking, nhiều BS share phòng. CRUD cơ bản chết sau 2 ngày demo.

Ngộ nhận của fresher

"Form/Survey chỉ là bảng questions + answers."

Reality check

Sếp: 'tôi muốn tự thêm câu hỏi, không cần dev hỗ trợ'. Bạn bị buộc vào EAV/JSONB/dynamic schema: pattern khó nhất của data modeling. Big Tech ít gặp. Internal tool ngày nào cũng gặp.

Ngộ nhận của fresher

"School/Course management: vài bảng students + classes."

Reality check

Cohort, section, period, prerequisite tree, weighted grading rubric, attendance theo session, transfer credit, parallel enrollment, GPA tính theo curriculum cũ hay mới. Business rule giáo dục VN chi tiết kinh khủng, chi tiết hơn cả TMĐT.

Ngộ nhận của fresher

"Multi-tenant SaaS chỉ cần thêm tenant_id mọi bảng."

Reality check

Đúng 30%. Còn lại: row-level security, noisy neighbor isolation, cross-tenant query cho admin, tenant-level customization, billing per tenant, soft-delete cascade. Quên tenant_id 1 query = data của tenant A lộ sang tenant B = mất hợp đồng + lawsuit. Đã từng xảy ra ở SaaS VN.

Đây là lý do 7/10 archetype trong khoá là internal-heavy. Rèn tư duy đúng = schema bạn design tech lead nhìn không phải sửa.

// Bạn đang nghĩ

"Tao có design schema từ đầu đâu? Khoá này không quan trọng với tao."

Câu này 7/10 fresher nghĩ trong đầu khi xem landing page khoá data modeling. Hợp lý, nhưng sai. Chính vì bạn KHÔNG design từ đầu, khoá này càng quan trọng. Đây là 5 lý do.

Lý do #1
"Thêm bảng / thêm cột" CHÍNH LÀ design schema
Bạn đang design từng mảnh nhỏ, không nhận ra. Mỗi field mới = 1 chuỗi quyết định: nullable hay NOT NULL? FK tới đâu? Unique hay không? Index? Denormalize hay tách bảng? Lưu giá trị hiện tại hay history? Mỗi câu trả lời sai = 1 hạt bug ngủ đông, đến tháng thứ 6 sếp hỏi 'lịch sử X' và bạn không có data. Không có pattern matching trong đầu = bạn quyết theo cảm tính. Khoá này cài pattern matching để mỗi quyết định nhỏ đều đúng.
Lý do #2
Đọc schema sẵn còn cần pattern hơn design từ đầu
Phần lớn thời gian backend fresher là READ schema cũ rồi extend, không phải gõ schema mới từ đầu. Bạn mở bảng `employees` thấy có cột `position_history_id` tham chiếu sang bảng `position_history` (valid_from, valid_to). Không biết temporal pattern = không hiểu vì sao thiết kế vậy, query sai khi tính lương tháng trước, push code, QA bắt được, tech lead hỏi 'sao không hỏi trước khi code'. Hiểu pattern = đọc 1 schema lạ trong 5 phút biết được logic business đằng sau, code không sai.
Lý do #3
Standup / code review nói pattern, không nói cú pháp SQL
Đồng nghiệp lâu năm: "cái này phải effective-date", "thêm idempotency key cho webhook", "làm soft-delete cascade", "chỗ này là ledger pattern, không UPDATE", "EAV phần custom field tách ra". Bạn google từng cái rồi quên, vì google không cho thấy chúng connect với nhau thành 1 pattern matching system. Không hiểu vocabulary = mù trong standup, làm theo lệnh không tranh luận được, không bao giờ promote.
Lý do #4
Phỏng vấn lên level LUÔN hỏi design schema
Ở job hiện tại bạn có thể trốn design, không trốn được khi đi phỏng vấn năm 2, năm 3. "Design schema cho hệ thống đặt phòng khách sạn", "Schema cho ví điện tử multi-currency", "Database cho LMS có quiz adaptive". Đây là câu chuẩn cho mọi backend 1-3 năm ở VN. Không có tư duy pattern matching trong đầu = ngồi 30 phút vẫn lúng túng, fail vòng kỹ thuật, ở lại job cũ với lương cũ.
Lý do #5
Tháng thứ 6 trở đi: sếp giao task, bạn TỰ design phần đó
Không ai cầm tay chỉ schema cho fresher mãi. "Mở rộng module HR thêm phần overtime", "Thêm tính năng coupon discount cho checkout", "Build chức năng audit log cho admin". Sếp giao task feature-level, bạn tự quyết schema phần đó. Nếu không có pattern matching, bạn copy cấu trúc bảng cũ → trúng pattern thì may, không trúng thì 3 tháng sau bug, tech lead review code chửi vì design thiếu. Cài tư duy pattern matching trong đầu trước khi đến mốc 6 tháng là cách rẻ nhất.

Không design từ đầu không có nghĩa là không cần biết design. Bạn vẫn quyết định schema mỗi ngày, chỉ là quyết từng mảnh nhỏ. Quyết đúng từng mảnh = career path mở. Quyết sai = tech debt + bug + sếp mất tin tưởng. Khoá này dành CHÍNH cho người không design từ đầu, vì người đó cần pattern matching hơn ai hết.

// Entry barrier

Khoá KHÔNG động vào 1NF/2NF/3NF, KHÔNG bắt vẽ ERD trên giấy

Bạn không cần thuộc lý thuyết để học được. Khoá đi ngược: làm trước, đặt tên sau. Đây là lý do.

Không cần thuộc định nghĩa 1NF/2NF/3NF

Vì khoá không hỏi 'schema này có ở 3NF không'. Khoá hỏi 'business có hỏi được câu này không'. Bạn design xong, mình mới nói 'à đây gọi là chuẩn 3NF'. Bạn nhớ vì đã làm, không nhớ vì đã thuộc.

Không cần biết vẽ ERD trên giấy đúng UML

Vì production không ai vẽ ERD trên giấy nữa. Mọi người gõ SQL trực tiếp, dùng DBML, hoặc tool như dbdiagram.io. Schema trong khoá viết bằng SQL CREATE TABLE: đọc được luôn, copy-paste vào job được luôn.

Không cần thuộc terms 'cardinality', 'tuple', 'relation'

Đây là vocabulary của giáo sư database. Standup không ai dùng. Khoá dùng vocabulary thật của dev VN: 'bảng', '1 dòng', 'quan hệ N-N', 'FK ref bảng X'. Quay lại học terms hàn lâm sau khi cần đọc paper.

Không cần biết khái niệm DDD/Aggregate/Bounded Context

Đây là kiến trúc level cao hơn. Khoá dừng ở data model: concrete, thấy được, viết SQL ra được. DDD là bước tiếp theo, học sau khi có nền tảng pattern.

Không cần biết SQL nâng cao (CTE, window function, recursive)

Khoá tập trung vào DESIGN schema, không phải truy vấn schema. SQL nâng cao có dùng vài chỗ, sẽ giải thích inline khi gặp. Biết SELECT/JOIN/GROUP BY là đủ start.

Cái BẠN cần biết trước: SQL cơ bản (SELECT/JOIN/GROUP BY) + 1 framework backend. Còn lại: khoá tự cài vào đầu bạn qua case study.

// Pedagogy

Cách content đi: vấn đề trước, định nghĩa sau

Hầu hết khoá SQL đi ngược: định nghĩa 1NF trước, ví dụ sau. 1 tuần là quên sạch. Content này đi theo flow não bộ thực sự nhớ: bạn vật lộn với vấn đề → tự thấy cần pattern → mình mới đặt tên. Hiểu why trước khi nhớ what.

Bước 1
Đập 1 vấn đề thực vào mặt bạn
Không định nghĩa. Không slide lý thuyết. 1 tình huống production: 1 bug, 1 query slow, 1 câu hỏi business mà schema hiện tại không trả lời được.
Ví dụ
VD: 'Sếp hỏi: tháng 3 năm ngoái có bao nhiêu nhân viên ở phòng IT?' Schema đơn giản (employees có cột department) không trả lời được. Tại sao? Bạn tự tìm ra.
Bước 2
Lùi 1 bước: business sẽ hỏi schema này điều gì?
Schema 'chuẩn lý thuyết' khác schema 'trả lời được business'. Trước khi vẽ bảng, list các câu hỏi business sẽ đặt, kể cả câu chưa hỏi nhưng chắc chắn sẽ hỏi sau 6 tháng.
Ví dụ
VD: HR system → business sẽ hỏi: lương người này 6 tháng trước · ai làm phòng X năm 2024 · quỹ lương theo tháng. Tất cả cần lịch sử → bạn TỰ THẤY cần temporal pattern.
Bước 3
Design schema → đặt tên pattern → nhớ vĩnh viễn
Đến lúc này bạn đã thấm vấn đề. Mình mới đặt tên: 'Đây là Temporal Pattern, gặp ở HRM, Insurance, Subscription...'. Bạn không nhớ định nghĩa, bạn nhớ trải nghiệm vật lộn.
Ví dụ
VD: Sau khi vật lộn với 'lương đổi theo thời gian', bạn tự thấy cần valid_from/valid_to. Mình connect: 'Pattern này tên Temporal. Áp dụng cho HR, ví điện tử (đổi hạn mức), subscription (đổi plan)...'

Học theo flow này, 6 tháng sau bạn vẫn nhớ. Không phải vì bạn ôn lại, mà vì bạn đã từng vật lộn thật, nhớ là chuyện hiển nhiên.

// Methodology

5 bước design schema: cách mình hướng dẫn bạn nghĩ

Không phải xem video rồi quên. Đây là 5 bước cụ thể bạn lặp lại trong MỌI lesson, MỌI bài tập. Học 12 lần = thành phản xạ. Đây là quy trình thật của dev đã đi làm production, bị giấu vì 'ai cũng nghĩ vậy mà', nhưng fresher không biết.

Anchor example: "Build app đặt lịch khám phòng khám đa khoa"

Bước 101
Đọc requirement: bắt từng danh từ và động từ
Không vẽ bảng ngay. Đọc requirement 2 lần. Highlight danh từ (entity tiềm năng) và động từ (action/event). Mỗi danh từ chưa chắc là 1 bảng. Mỗi động từ thường là 1 event cần lưu lại.
Ví dụ
Phòng khám → highlight: bệnh nhân, bác sĩ, phòng, lịch hẹn, đặt, huỷ, khám, kê đơn. 8 danh từ/động từ, không phải 8 bảng. Đó chỉ là raw material.
Bước 202
Naive schema: vẽ phiên bản ngu nhất có thể
Vẽ schema phiên bản đầu tiên CỐ TÌNH thiếu sót. Mỗi danh từ = 1 bảng, mỗi quan hệ = 1 FK. Không nghĩ pattern, không nghĩ edge case. Naive schema là baseline để tấn công.
Ví dụ
patients (id, name, phone) · doctors (id, name, specialty) · appointments (id, patient_id, doctor_id, date_time, status). 3 bảng. Trông OK. Sẵn sàng bị đập.
Bước 303
Hỏi 7 câu business: đập naive schema gãy
Mang 7 câu hỏi business khoá cung cấp ra hỏi naive schema. Câu nào schema không trả lời được = chỗ thiếu. Không sửa ngay, list ra hết. Đây là bước hầu hết fresher skip, và chính nó tách schema 'trông OK' khỏi schema production.
Ví dụ
Hỏi: 1) BS này thường làm ca sáng hay chiều? 2) Lịch sử lần khám của BN A? 3) Sao BN B đặt 2 lịch trùng giờ? 4) Nghỉ lễ huỷ tự động? 5) Phòng nào trống lúc 10h? → naive schema gãy 5/7. Tốt, bây giờ biết phải thêm gì.
Bước 404
Nghĩ về thời gian: past, present, future
Hỏi 3 câu: (a) Giá trị này có lịch sử không? (b) Giá trị này có hiệu lực từ-đến không? (c) Tương lai có cần truy vấn 'lúc T thì sao' không? Nếu YES bất kỳ câu nào → temporal pattern. KHÔNG được UPDATE, INSERT history.
Ví dụ
BS đổi specialty: lịch sử cần (audit). Giá khám đổi: hiệu lực từ-đến cần (đối soát). Lương BS thay theo tháng: tương lai sếp sẽ hỏi 'lương BS A tháng 3' (chắc chắn). → temporal pattern cho cả 3.
Bước 505
Đặt tên pattern: connect với 9 domain khác
Đến lúc này schema đã đủ tốt cho phòng khám. Mình mới đặt tên: 'cái bạn vừa làm tên là Time-Slot Availability + Temporal Pricing'. Bạn nhận ra: pattern này dùng được cho salon, sân bóng, coworking, doctor-on-demand. 1 lần làm = 5 domain áp dụng.
Ví dụ
Pattern: Time-Slot Availability. Áp dụng: phòng khám · salon · sân bóng · coworking · BS gia đình. Đổi 'doctor' thành 'stylist' / 'sân' / 'phòng họp' / 'BS riêng', cấu trúc bảng giữ nguyên gần như hoàn toàn, chỉ đổi tên cột và FK.

5 bước này lặp 12 lần qua 12 module. Hết khoá: bạn không cần nhớ 5 bước, não bạn TỰ chạy chúng khi nhìn requirement. Đó là khoảng cách 2 năm tự mò mẫm bạn vừa tiết kiệm được.

// Mindset Shifts

4 cú nhảy tư duy giữa Fresher và người đã đi làm

Người đi làm lâu không 'biết SQL nhiều hơn bạn'. Họ nghĩ KHÁC bạn trước khi gõ phím. Khoá này cài 4 cách nghĩ này vào đầu bạn. Đó là phần lớn giá trị bạn nhận được, không phải SQL syntax.

Shift #1

Fresher nghĩ

"Bảng này cần cột gì? id, name, email, phone, status, created_at, updated_at. Xong."

Dev đi làm lâu nghĩ

"Business sẽ hỏi schema này điều gì trong 6 tháng tới? Top N theo X? Lịch sử Y? Count theo thời gian Z? Cột nào cần để mọi câu hỏi đều trả lời được trong 1 query, không bắt frontend tự tính?"

Shift #2

Fresher nghĩ

"Đề cho 5 entity → tạo 5 bảng → normalize lên 3NF cho chuẩn. Càng chuẩn càng tốt."

Dev đi làm lâu nghĩ

"Chuẩn 3NF nhưng query trang chủ JOIN 8 bảng → 3 giây load → user bỏ. Chỗ nào denormalize có chủ đích để cắt JOIN? Chỗ nào giữ chuẩn để tránh anomaly? Trade-off chứ không phải dogma."

Shift #3

Fresher nghĩ

"Lương đổi → UPDATE bảng employees. Tồn kho xuất → UPDATE quantity. Đơn paid → UPDATE status. SQL có UPDATE để làm gì nếu không dùng?"

Dev đi làm lâu nghĩ

"UPDATE = mất lịch sử. Sếp hỏi 'lương A 6 tháng trước' → không có. Audit hỏi 'tại sao mất 5 sản phẩm' → không trace được. INSERT history/ledger giữ trace. Chỉ UPDATE khi 100% chắc không ai cần giá trị cũ."

Shift #4

Fresher nghĩ

"1 app, mọi user dùng chung. Bảng users, products, orders. Đơn giản, rõ ràng, dễ debug."

Dev đi làm lâu nghĩ

"Khách hàng A và B share DB. Quên tenant_id 1 query → data A lộ sang B → mất hợp đồng + lawsuit. Tenant-aware từ ngày 1, không retrofit sau. Retrofit multi-tenant = 6 tháng + rewrite 200 query."

Học xong khoá, nhìn bất kỳ requirement nào, 4 câu hỏi này tự chạy trong đầu bạn. Khoảng cách giữa 'biết SQL' và 'biết design schema' nằm đúng ở đây.

// USP

4 thứ bạn nhận được mà khoá SQL khác không có

Không phải khoá DDD sách dịch. Không phải SQL 101. Đây là content tập trung đúng 1 thứ: cách design data model cho job backend ở VN, và đi thật sâu.

10 archetype case · Sân tập cho domain job VN

Booking · Inventory Ledger · EAV Form · Temporal HR · State Machine Shipping · Medical Episode · Double-entry Payment · Education Progress · Tiered Ticketing · Multi-tenant SaaS. 10 archetype để bạn lặp tư duy 12 lần, phản xạ pattern matching cho phần lớn domain backend fresher/junior VN: e-commerce, fintech, logistics, SaaS, HR, healthcare, edu. Không phải khoá Big Tech FAANG, đó không phải job market của bạn.

Học từ vấn đề, không học định nghĩa

Mỗi lesson bắt đầu bằng 1 production bug hoặc câu hỏi business không trả lời được. Bạn vật lộn với vấn đề trước → tự thấy cần pattern gì → mình mới đặt tên. Không phải nghe định nghĩa rồi quên trong 2 ngày.

Internal-first · Đúng với phần lớn job fresher VN

Sự thật: phần lớn job backend fresher/junior VN là build hệ thống nội bộ cho outsource/SME/startup, không phải clone Big Tech (TMĐT lớn, ví điện tử, siêu app). 7/10 archetype trong khoá là internal-heavy. Bạn rèn tư duy cho cái sẽ làm thật, không phải cái nghe ngầu trên YouTube.

Pattern matching → áp dụng cho domain chưa từng làm

Module cuối hướng dẫn nhận diện signal words. 'Đặt lịch' → Time-Slot. 'Tồn kho' → Ledger. 'Custom field' → EAV. 'Lịch sử thay đổi' → Temporal. Học 1 lần. Áp dụng được cho ngành bạn chưa bao giờ đụng vào, bao gồm ngành 5 năm sau bạn mới biết tới.

// Curriculum

12 module · 10 archetype sân tập tư duy

Mỗi module = 1 archetype case để bạn lặp lại quy trình tư duy. 10 archetype này pattern-match được phần lớn domain backend fresher/junior VN trong 5 năm đầu (e-commerce, fintech, logistics, SaaS, HR, healthcare...). Domain hiếm gặp hơn, dùng meta-pattern ở M12 để tự research bằng cùng cách nghĩ.

5 production bug khét tiếng VN: root cause ở data model
1 business question đập gãy 1 schema: 'có bao nhiêu...', 'lịch sử...', 'top N theo...'
Entity vs Attribute vs Value: khi nào tách bảng, khi nào chỉ cột
Cardinality 1-1/1-N/N-N: frame qua 'khi nào câu hỏi cần count many'
Normalization không phải mục tiêu, chỉ là hệ quả của 'mỗi fact 1 chỗ'
Primary/Foreign key, Index: chọn theo 'query nào chạy mỗi giây'
Đọc requirement như người đã đi làm 3-5 năm: bóc câu hỏi business ẩn sau user story

Resource × TimeSlot × Reservation: tam giác cốt lõi
Tránh double-booking: unique constraint, optimistic locking
Recurring schedule: weekly availability + exception (nghỉ lễ)
Cancellation, no-show, waitlist auto-fill
Buffer time, group booking (capacity > 1)
Vocabulary: slot · reservation · resource · availability · recurring · capacity

Vì sao KHÔNG UPDATE quantity, luôn StockMovement
IN/OUT/TRANSFER/ADJUSTMENT: 4 loại movement
Multi-warehouse: tồn theo location
Reservation: chống oversell khi flash sale
Lot/Batch tracking, FIFO/LIFO, expiry date
Vocabulary: SKU · UOM · stock movement · reorder point · safety stock · lot

EAV là gì, vì sao cần khi 'không biết trước schema'
EAV vs JSONB vs Sticky table: 3 lựa chọn + trade-off
Form definition × Form response: tách template và submission
Validation rule lưu DB (regex, range, required)
Conditional logic: hỏi câu B nếu câu A = X
Vocabulary: EAV · schemaless · JSONB · dynamic field · form template

Vì sao KHÔNG UPDATE position/salary: history table
Effective date range: pattern (valid_from, valid_to)
Employee × Position × Department: 3-way assignment qua thời gian
Payroll snapshot: lương tháng này tính theo position lúc nào
Leave balance: accrual, carryover, expiry
Vocabulary: temporal · effective date · snapshot · accrual · FTE · headcount

State machine: state · event · transition · guard
Shipment lifecycle: created → picked → in-hub → out-for-delivery → delivered
Multi-leg shipment: 1 đơn qua nhiều hub, nhiều shipper
Handoff: ai đang giữ đơn, trách nhiệm chuyển khi nào
Exception flow: failed delivery, return-to-sender, COD reconciliation
Vocabulary: AWB · hub · sortation · last-mile · COD · RTS · handoff

Patient × Encounter × Record: tách rõ patient và lượt khám
Episode of care: 1 ca bệnh kéo dài nhiều encounter
EMR: vital, diagnosis (ICD-10), procedure
Prescription, lab result, imaging: schema cho mỗi loại record
Billing & Insurance: BHYT, copay, claim flow
Vocabulary: patient · encounter · episode · EMR · ICD-10 · BHYT

Double-entry ledger: vì sao Fintech KHÔNG UPDATE balance
Transaction state machine: initiated → pending → success/failed/refunded
Idempotency key: webhook payment cần unique key thế nào
Settlement & Reconciliation: đối soát cuối ngày
KYC, AML, audit log: compliance VN, data protection cơ bản
Vocabulary: ledger entry · settlement · reconciliation · idempotency · KYC

Course × Class × Section × Enrollment: phân biệt + quan hệ
Progress tracking: lesson completion, watch time, quiz score
Attendance: present/absent/late theo session
Grading: rubric, weighted score, GPA calculation
Curriculum prerequisite: dependency tree giữa courses
Vocabulary: enrollment · section · rubric · GPA · prerequisite · cohort

Event × Ticket Type × Seat: 3 layer model
Tiered pricing: nhiều hạng vé, quota riêng
Seat assignment vs general admission
Hold/Reservation với expiry (giữ vé 10 phút khi checkout)
Refund & transfer ticket: schema cho secondary market
Vocabulary: tier · quota · hold · GA · allocation · no-show

3 chiến lược: pool · bridge · silo, chọn khi nào
Tenant ID column everywhere: foreign key cascade
Row-level security (RLS) trong PostgreSQL
Workspace × Org × User × Membership: hierarchy phổ biến
Plan, subscription, usage metering: billing schema
Vocabulary: tenant · workspace · org · membership · RLS · noisy neighbor

Map 10 archetype → meta-pattern: Ledger · State Machine · Temporal · Polymorphic · Hierarchy
Pattern combination: 1 hệ thống thường mix 3-5 pattern
Signal words → archetype: dò pattern khi đọc requirement
Anti-pattern fresher hay mắc + cách tránh
Khi nào break rule: pragmatic choice trong production
Roadmap tự research 1 domain mới khi vào job mới

// Click vào module để xem chi tiết các bài học

// Hard Questions

3 câu hỏi bạn sẽ không hỏi trực tiếp

Vì nếu hỏi thẳng thì sợ quê. Mình trả lời hộ. Cả 3 đều là câu thật, mình nghe từ fresher VN đã pre-test landing này. Mỗi câu một lý do khác nhau vì sao khoá vẫn xứng đáng.

#01 · Money objection

“Sao không học miễn phí trên YouTube / freeCodeCamp / blog dev?”

✕ Free YouTube / Blog

✓ Khoá này

Nội dung

✕ Free YouTube / Blog

Dạy pattern đơn lẻ. EAV 1 video, Ledger 1 video, Temporal 1 video. Rời rạc.

✓ Khoá này

Cài tư duy pattern matching vào đầu bạn. 10 archetype làm sân tập, lặp 12 lần đến khi nhìn requirement đoán đúng archetype thành phản xạ.

Context

✕ Free YouTube / Blog

Tutorial tiếng Anh, domain US/EU: Stripe clone, Notion clone, Twitter clone. Không map với job VN.

✓ Khoá này

100% domain VN: BHYT, phần mềm kế toán SME, POS bán lẻ, HR nội địa, F&B, edu, fintech B2C. Compliance VN, audit thực tế, data protection cơ bản.

Sequencing

✕ Free YouTube / Blog

Bạn tự lo. Học 6 tháng rời rạc, vẫn không biết 'bây giờ cần học gì tiếp'.

✓ Khoá này

12 module có flow rõ. Mỗi archetype lặp 5 bước design, dồn thành phản xạ tư duy.

Vocabulary

✕ Free YouTube / Blog

Mỗi video 1 thuật ngữ, không có dictionary. Quên trong 2 ngày.

✓ Khoá này

60+ thuật ngữ production VN, bạn TỰ nói được trong standup vì hiểu cách nghĩ đằng sau, không phải nhớ.

Community

✕ Free YouTube / Blog

Comment YouTube vô tri. Stack Overflow lệch domain. Discord random không trả lời schema VN.

✓ Khoá này

Discord/Zalo + Q&A live hàng tuần. Post schema → mình và community review async.

#02 · Level objection