A2 · Kiến thức domain và ngôn ngữ chung
Mỗi domain có quy tắc riêng: ngân hàng (sổ cái kép, đối soát, không xóa giao dịch mà ghi bút toán đảo), ERP/SAP (mua – bán – kho – kế…
A2 · Middle
Làm phần mềm ngân hàng mà không hiểu "bút toán", "đối soát" giống như phiên dịch mà không biết nghĩa của từ: dịch trôi chảy nhưng sai.
Cốt lõi
- Mỗi domain có quy tắc riêng: ngân hàng (sổ cái kép, đối soát, không xóa giao dịch mà ghi bút toán đảo), ERP/SAP (mua – bán – kho – kế toán liên kết chặt), thương mại điện tử (tồn kho, khuyến mãi, vận chuyển).
- Ngôn ngữ chung (Ubiquitous Language trong DDD): code dùng đúng thuật ngữ nghiệp vụ, cả đội hiểu như nhau.
- Bounded context: cùng một từ có thể mang nghĩa khác nhau ở mỗi bộ phận ("khách hàng" của bán hàng khác "khách hàng" của kế toán).
Đánh đổi
Kiến thức domain tích lũy chậm nhưng khó thay thế, đó là lý do ngân hàng hay các dự án SAP thường yêu cầu kinh nghiệm domain cao.
Trong thực tế
Ví điện tử không lưu số dư như một con số bị sửa trực tiếp, mà là tổng các bút toán – sai ở đâu cũng truy vết được.
Bug thường gặp
Sửa trực tiếp cột balance thay vì ghi bút toán → khi số dư sai, không còn dấu vết để biết sai từ giao dịch nào.
Tự hỏi lại
Domain-Driven Design giúp gì khi hệ thống và đội ngũ lớn dần?
A1 · Hiểu bài toán nghiệp vụ trước khi viết code
Xác định ai dùng, họ cần đạt được gì, luồng chính và các trường hợp ngoại lệ nghiệp vụ (hủy, hoàn, hết hạn, sửa sau khi đã chốt).
A3 · Yêu cầu phi chức năng và thiết kế vừa đủ
Yêu cầu phi chức năng: số người dùng, lượng request, độ trễ chấp nhận được, mức sẵn sàng (99,9%?), bảo mật, yêu cầu pháp lý.