# Mô hình tư duy là gì **(Mô hình tư duy(Mental Model )**là cách mà một người **tưởng tượng, hiểu và lý giải cách một hệ thống, quy trình, hoặc một lĩnh vực hoạt động**. Nói đơn giản, đó là **bức tranh trong đầu mỗi người** về thế giới thật — và bức tranh này có thể **khác nhau giữa từng người**. #### Trong bối cảnh Domain-Driven Design (DDD): - Mô hình tư duy là cách mà **các bên liên quan (domain expert, developer, khách hàng)** hiểu về domain (lĩnh vực nghiệp vụ). - Nếu mỗi người có một Mô hình tư duy khác nhau, dễ dẫn đến **hiểu nhầm**, **thiết kế sai**, hoặc **phần mềm không đáp ứng đúng nhu cầu thực tế**. Ví dụ
**Vai trò****Mental Model về “Lô hàng”**
Nhân viên khoMột lần xe chở hàng vào kho = 1 lô hàng
Kế toánMột đơn hàng có thể nhập thành nhiều lô
Lập trình viên (dev)Một dòng trong bảng `Shipments` trong DB
Nếu không trao đổi để thống nhất, thì phần mềm sẽ **thiết kế sai với thực tế**. Tại sao Mental Models quan trọng trong DDD? #### **1. Mô hình tư duy & sự đồng bộ trong thiết kế** - Việc xây dựng **mô hình tư duy (mental model)** chung giúp **đồng bộ hóa thiết kế phần mềm** với lĩnh vực nghiệp vụ. - Trong thực tế, chúng ta thường gặp tình huống phải **diễn đạt lại ý tưởng** hoặc tiếp cận từ góc nhìn khác để được hiểu đúng – điều này phơi bày **sự phức tạp của giao tiếp**. - Trong DDD, **khác biệt về mô hình tư duy** giữa các bên liên quan có thể dẫn đến phần mềm **lệch chuẩn nhu cầu nghiệp vụ**. #### **2. Vai trò then chốt của mô hình tư duy** - Cách nó **làm cầu nối** giữa **góc nhìn kỹ thuật** và **yêu cầu nghiệp vụ** - Hiểu rõ **động lực giao tiếp** thông qua mô hình tư duy chung giúp phát triển phần mềm **sát với mục tiêu nghiệp vụ** và **nhu cầu người dùng**. #### **3. Thách thức trong giao tiếp** - **Truyền đạt sai** dẫn đến **hiểu nhầm yêu cầu**, **sai lệch mục tiêu**, và cuối cùng là phần mềm **không đáp ứng nhu cầu**. - Thành công phụ thuộc vào **kinh nghiệm chia sẻ** giữa các thành viên. Mỗi tương tác góp phần xây dựng **mô hình tư duy chung**, giúp hiểu thông tin sâu sắc hơn. - Trong môi trường đa ngành (như phát triển phần mềm), mô hình tư duy chung **thu hẹp khoảng cách** giữa đội ngũ kỹ thuật và Các bên liên quan(stakeholders). #### **4. Rào cản từ phụ thuộc vào tài liệu** - **Tài liệu chi tiết** không thể thay thế **giao tiếp trực tiếp**. Nếu người đọc không chia sẻ mô hình tư duy với tác giả, dễ xảy ra hiểu lầm. - Ở các tập đoàn lớn, **khoảng cách giữa phòng kinh doanh và kỹ thuật** càng trầm trọng – không chỉ về địa lý mà còn về **tư duy**. #### **5. Xung đột giữa mục tiêu nghiệp vụ và kỹ thuật** - **Business stakeholders** tập trung vào ROI, trải nghiệm khách hàng. - **Kỹ sư** quan tâm đến kiến trúc, công nghệ. - Sự khác biệt này gây khó khăn trong việc **chuyển đổi nhu cầu kinh doanh thành giải pháp kỹ thuật**. #### **6. Hạn chế của mô hình truyền thống (Waterfall)** - Phân tách rõ ràng các giai đoạn (requirements, design, dev, test) làm **trầm trọng hóa khoảng cách**. - Business analyst đóng vai trò "phiên dịch", nhưng việc **chuyển đổi tầng tầng lớp lớp** dễ gây hiểu sai. - Giả định rằng **kỹ sư có thể tự hiểu vấn đề nghiệp vụ phức tạp** là sai lầm. #### **7. Hậu quả của thiếu đồng bộ** - **Lệch mục tiêu**: Dev tập trung vào công nghệ mới thay vì nhu cầu nghiệp vụ → phần mềm không giải quyết đúng vấn đề. - **Tốn tài nguyên**, sản phẩm lỗi, **phải làm lại**. - **Mất niềm tin**: Stakeholder siết kiểm soát → đội ngũ tập trung vào "hoàn thành task" thay vì chất lượng. - **Bỏ qua testing/refactor** → rủi ro hệ thống sụp đổ. #### **8. Giải pháp then chốt** - **Mô hình tư duy chung** là chìa khóa. - **Giao tiếp trực tiếp**, minh bạch, xây dựng niềm tin. - **Tránh phụ thuộc quá mức vào tài liệu** – chỉ giao tiếp mới phá vỡ rào cản. #### **9. Kết luận** - **Cân bằng mô hình tư duy** ngăn thất bại dự án, đảm bảo phần mềm **linh hoạt, đúng nhu cầu, dễ bảo trì**. **Câu hỏi mở**: Làm thế nào để đạt được sự đồng bộ này? **Tác giả: Đỗ Ngọc Tú** **Công Ty Phần Mềm [VHTSoft](https://vhtsoft.com/ "Công Ty Phần Mềm VHTSoft")**