FIG. 1 — TRƯỚC KHI CÓ DDD
Một cái kho, cái gì cũng chất chung
Không chia khu vực → ai cũng táy máy đồ của người khác. Sửa một chỗ, hỏng năm chỗ.
Mọi thứ chất trong 1 phòng, ai cũng nối tắt vào đồ của người khác — không ai còn nhớ nổi cái gì phụ thuộc cái gì.
FIG. 2 — Ý TƯỞNG CỦA DDD
Vẽ lại thành từng phòng riêng
Đơn Hàng, Kho, Thanh Toán — mỗi phòng một việc, chỉ nối với phòng bên cạnh qua đúng một cái cửa.
Mỗi phòng (bounded context) tự quản đồ đạc của mình, chỉ nối với phòng khác qua một cửa duy nhất.
FIG. 3 — LUẬT SỐ 1: NGÔN NGỮ CHUNG
Sales gọi sao, code viết vậy
Người kinh doanh nói "đơn hàng" — trong code cũng phải là "đơn hàng", không phải Object2 hay data_x.
Ubiquitous Language: từ business dùng ngoài đời phải xuất hiện y hệt trong tên class, tên hàm.
FIG. 4 — LUẬT SỐ 2: GÕ CỬA, ĐỪNG CHUI TƯỜNG
Muốn đổi gì trong phòng? Phải qua đúng cửa
Không ai được thò tay sửa trực tiếp đồ đạc của phòng khác — phải gọi đúng qua cửa để phòng đó tự kiểm tra trước khi đổi.
Rich domain model: thay đổi trạng thái luôn đi qua một "cửa" (method) tự kiểm tra, không cho gán field trực tiếp từ bên ngoài.
FIG. 5 — LUẬT SỐ 3: BÁO TIN, ĐỪNG ÔM VIỆC
Xong việc thì gửi tin, không tự chạy sang phòng khác làm hộ
Phòng Kho đóng gói xong → gửi một tờ tin "đã đóng gói" → phòng Vận Chuyển tự nghe và tự làm phần của mình.
Domain Event: phòng phát tin xong là xong việc — phòng nghe tin tự quyết định làm gì tiếp, không ai gọi thẳng vào nội bộ ai.
CHÚ GIẢI BẢN VẼ
Domain là trung tâm
Nghiệp vụ quyết định thiết kế, không phải database hay framework.
Ngôn ngữ chung
Code và người kinh doanh gọi cùng một khái niệm bằng cùng một từ.
Ranh giới rõ ràng
Mỗi phòng (bounded context) tự quản việc của mình, không đọc/ghi lẫn nhau.
Tự bảo vệ chính mình
Mọi thay đổi trạng thái phải đi qua đúng cửa (method) hợp lệ.