Kiến trúc hệ thống (bức tranh lớn)

Kiến trúc hệ thống là gì?

Mọi sản phẩm số bạn đang làm — app thương mại điện tử, ví điện tử, trang quản trị nội bộ — đều được xếp thành ba lớp. Không cần biết code để hiểu ba lớp này; chỉ cần biết mỗi lớp chịu trách nhiệm việc gì.

Frontend: thứ người dùng nhìn thấy và chạm vào — nút, form, danh sách, thông báo trên màn hình.

Backend: nơi chứa luật nghiệp vụ. Nó quyết định điều gì được phép xảy ra: còn hàng không, người này có quyền không, giá cuối cùng là bao nhiêu.

Database: nơi dữ liệu được ghi xuống và đọc lên — đơn hàng, người dùng, giao dịch, tồn kho.

Hệ quả quan trọng nhất với BA/PO: effort của một yêu cầu không tỉ lệ với việc nó trông lớn hay nhỏ trên màn hình, mà tỉ lệ với số lớp bị chạm. Đổi màu nút chỉ chạm một lớp. Đổi cách tính phí ship chạm cả ba.

Baseline — bạn hiểu

• Sản phẩm có 3 lớp: frontend (UI — thứ người dùng thấy và chạm), backend (luật quyết định điều gì xảy ra), database (nơi lưu và lấy dữ liệu).
• Một hành động của người dùng đi qua cả ba lớp rồi mới có kết quả trên màn hình.
• Khi ai đó nói "lỗi này ở backend", bạn hiểu họ đang nói về lớp nào và loại việc gì.

Working — bạn làm được

• Tính được quyết định ở frontend/backend/database ảnh hưởng thế nào tới feasibility, effort và performance khi thiết kế feature — gồm cả state và phụ thuộc bên thứ ba.
• Nhìn một yêu cầu và nói được nó chạm lớp nào, có cần đổi cấu trúc dữ liệu không, có gọi dịch vụ bên ngoài không.
• Viết vào ticket: dữ liệu lấy từ đâu, phần nào bắt buộc phải có, và màn hình hiện gì khi một nguồn bị lỗi.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Bấm "Thêm vào giỏ" thì chuyện gì xảy ra?

Tình huống: bạn đang viết ticket cho nút "Thêm vào giỏ" và muốn biết mình đang nói về phần nào của hệ thống.

Chuỗi sự việc thật, theo đúng thứ tự:

1. Frontend: người dùng bấm nút. App gửi đi một yêu cầu: "thêm sản phẩm 812, số lượng 1, cho người dùng đang đăng nhập".
2. Backend: kiểm tra các luật — người này đã đăng nhập chưa, sản phẩm 812 còn bán không, còn tồn kho không, có giới hạn mỗi người 2 cái không.
3. Database: nếu mọi luật đều qua, ghi một dòng mới vào bảng cart_items, rồi đọc lại toàn bộ giỏ của người dùng đó.
4. Backend: gói kết quả lại — giỏ hiện có 3 món, tạm tính 450.000đ — và trả về.
5. Frontend: đổi số trên icon giỏ hàng thành 3 và hiện thông báo "Đã thêm vào giỏ".

Học được: "nút không chạy" là một câu mô tả rỗng — nó có thể hỏng ở bất kỳ bước nào trong năm bước trên. Biết chuỗi này thì bạn biết phải hỏi gì tiếp theo.

Trung bình — Hai yêu cầu trông giống nhau, effort chênh nhau nhiều lần

Tình huống: trong cùng một buổi refinement có hai yêu cầu, cả hai đều được stakeholder mô tả là "sửa nhỏ thôi".

Câu hỏi cần hỏi ngay tại buổi refinement: "Yêu cầu này có cần chỗ lưu dữ liệu mới không? Nếu có thì đơn hàng cũ hiển thị thế nào?"

Học được: độ lớn của thay đổi trên màn hình không nói gì về effort. Số lớp bị chạm mới nói. Và mỗi khi có dữ liệu mới, luôn có một câu hỏi kèm theo về dữ liệu cũ.

Nâng cao — Màn hình gộp dữ liệu từ nhiều nguồn

Tình huống: bạn spec màn hình "Chi tiết đơn hàng". Trên đó có bốn nhóm thông tin, và chúng đến từ bốn nơi khác nhau:

• Thông tin đơn (mã đơn, sản phẩm, tổng tiền) — database chính của mình.
• Trạng thái thanh toán — service thanh toán nội bộ.
• Điểm thưởng được cộng — service điểm thưởng nội bộ.
• Vị trí kiện hàng — API của đơn vị vận chuyển (GHN/GHTK), nằm ngoài tầm kiểm soát của mình.

Cái bẫy: nếu spec chỉ viết "hiển thị đầy đủ thông tin đơn hàng", dev sẽ gọi cả bốn nguồn rồi mới vẽ màn hình. Hôm nào API vận chuyển chậm 8 giây thì cả trang trắng 8 giây, dù ba nhóm còn lại đã sẵn sàng từ lâu. Tệ hơn: API đó lỗi thì màn hình báo lỗi toàn trang, khách không xem được đơn của chính mình.

Cách viết spec cho đúng — phân loại từng nguồn:

• Bắt buộc: thông tin đơn và trạng thái thanh toán. Thiếu là không mở được màn hình.
• Tải sau, độc lập: điểm thưởng và vị trí kiện hàng. Màn hình hiện ngay, hai ô này hiện trạng thái đang tải rồi tự điền vào sau.
• Khi nguồn ngoài lỗi hoặc quá 3 giây: ô vận chuyển hiện "Chưa lấy được thông tin vận chuyển. Thử lại" — phần còn lại của trang vẫn dùng bình thường.
• Ghi rõ mốc dữ liệu: vị trí kiện hàng là thông tin phía vận chuyển cập nhật theo chu kỳ, nên hiện kèm "cập nhật lúc 14:20".

Học được: mỗi nguồn dữ liệu thêm vào một màn hình là thêm một điểm chậm và một điểm hỏng. Vẽ ra các nguồn trước khi viết acceptance criteria là cách rẻ nhất để phát hiện điều đó — rẻ hơn nhiều so với phát hiện ở tuần đầu sau khi lên production.

Áp dụng khi viết spec

Với mỗi yêu cầu, ticket của bạn nên trả lời được bốn câu:

1. Yêu cầu này chạm lớp nào — chỉ giao diện, hay cả luật nghiệp vụ và dữ liệu?
2. Có cần lưu thêm dữ liệu mới không? Nếu có, dữ liệu cũ hiển thị ra sao?
3. Màn hình này lấy dữ liệu từ mấy nguồn? Nguồn nào bắt buộc, nguồn nào có thể tải sau?
4. Nếu một nguồn chậm hoặc lỗi thì người dùng thấy gì?

Câu hỏi nên hỏi dev

• "Thay đổi này nằm ở lớp nào — frontend, backend hay cả database?"
• "Có cần thêm cột hay đổi cấu trúc dữ liệu (migration) không?"
• "Màn này đang lấy dữ liệu từ mấy nguồn? Có nguồn nào là dịch vụ bên ngoài không?"
• "Nếu nguồn ngoài lỗi thì hiện tại màn hình xử lý thế nào?"
• "Dữ liệu này có đang được cache không, và cache cũ tối đa bao lâu?"

Sai lầm thường gặp

• Ước lượng effort theo độ lớn của thay đổi trên giao diện thay vì theo số lớp bị chạm.
• Nghĩ "chỉ là đổi chữ" trong khi đoạn chữ đó do backend trả về theo từng trường hợp.
• Thêm trường dữ liệu mới mà không nói dữ liệu cũ hiển thị gì — đến lúc test mới phát hiện 200.000 đơn cũ để trống.
• Coi dịch vụ bên thứ ba là luôn sẵn sàng và luôn nhanh.
• Viết acceptance criteria chỉ cho trường hợp mọi nguồn dữ liệu đều trả về đúng.

Definition of done — dấu hiệu bạn đã đạt

• Chỉ vào bất kỳ feature nào trong khu vực của mình, bạn nói được nó chạm lớp nào.
• Ticket của bạn luôn ghi nguồn dữ liệu và hành vi khi nguồn đó lỗi.
• Bạn không cam kết timeline trước khi biết yêu cầu có cần đổi cấu trúc dữ liệu hay không.

Đi sâu hơn

• Backend (Logic nghiệp vụ) — gọi tên đúng service sở hữu feature.
• Database (Lưu trữ dữ liệu) — dữ liệu sống ở đâu và đọc nó tốn gì.