Phân tích thiết kế hệ thống thông tin quản lý

Bài 16. Domain Model – Mô hình hóa miền nghiệp vụ

“Nếu Use Case mô tả hệ thống làm gì, thì Domain Model mô tả hệ thống đang quản lý những gì.”

Theo tôi, Bài 16 là bài bản lề của toàn bộ học phần.

Đây là lúc sinh viên bắt đầu trả lời câu hỏi:

“Hệ thống đang quản lý những gì?”

Tôi cũng muốn thay đổi một cách tiếp cận rất phổ biến trong nhiều giáo trình.

Rất nhiều tài liệu dạy ngay Class Diagram.

Đó là một sai lầm.

Một System Analyst không thiết kế Class trước.

Họ phải hiểu Domain trước.

Nếu chưa hiểu miền nghiệp vụ thì mọi Class Diagram chỉ là những hộp chữ nhật nối với nhau.

Đó là lý do tôi muốn dành riêng một bài cho Domain Model trước khi học Class Diagram.

Vị trí của bài học trong chuỗi bài

Business Problem
        ↓
Stakeholder
        ↓
AS-IS Process
        ↓
TO-BE Process
        ↓
Requirement Engineering
        ↓
Use Case
        ↓
Activity Diagram
        ↓
Sequence Diagram
        ↓
Domain Model   ← Bạn đang ở đây
        ↓
Class Diagram
        ↓
Database Design

Mục tiêu bài học

Sau khi hoàn thành bài học này, bạn có thể:

  • Hiểu khái niệm Domain Model.
  • Xác định các thực thể (Domain Entity) trong hệ thống.
  • Phân biệt Domain Model và Class Diagram.
  • Xây dựng Domain Model từ Requirement và Use Case.
  • Tránh các sai lầm phổ biến khi mô hình hóa miền nghiệp vụ.

1. Từ hành vi đến cấu trúc

Ở các bài trước, chúng ta tập trung vào hành vi của hệ thống.

Ví dụ:

  • Đăng nhập.
  • Đăng ký học phần.
  • Thanh toán học phí.
  • Mượn sách.
  • Trả sách.

Những mô hình đó trả lời:

Hệ thống làm gì?

Nhưng để thiết kế hệ thống, còn một câu hỏi quan trọng khác:

Hệ thống cần quản lý những đối tượng nào?

Ví dụ trong hệ thống đăng ký học phần.

Ta dễ dàng nhận thấy:

  • Sinh viên
  • Học phần
  • Giảng viên
  • Lớp học phần
  • Học kỳ

Đây chính là các khái niệm của miền nghiệp vụ.

2. Domain là gì?

Trong kỹ nghệ phần mềm, Domain là lĩnh vực nghiệp vụ mà hệ thống phục vụ.

Ví dụ:

  • Hệ thống thư viện → Domain là quản lý thư viện.
  • Hệ thống bệnh viện → Domain là quản lý khám chữa bệnh.
  • Hệ thống bán hàng → Domain là thương mại.
  • Hệ thống đào tạo → Domain là quản lý đào tạo.

Nói cách khác.

Domain không phải là phần mềm.

Domain là thế giới thực mà phần mềm đang mô phỏng và hỗ trợ.

3. Domain Model là gì?

Domain Model là mô hình biểu diễn:

  • Các khái niệm quan trọng của miền nghiệp vụ.
  • Thuộc tính chính của từng khái niệm.
  • Quan hệ giữa các khái niệm.

Nó không mô tả:

  • Giao diện.
  • Thuật toán.
  • API.
  • Cơ sở dữ liệu.

Domain Model chỉ tập trung vào ngôn ngữ và cấu trúc của nghiệp vụ.

4. Xác định Domain Entity

Một kỹ thuật đơn giản là đọc Requirement hoặc Use Case và tìm các danh từ quan trọng.

Ví dụ:

Use Case:

Sinh viên đăng ký học phần trong học kỳ.

Các danh từ xuất hiện:

  • Sinh viên
  • Học phần
  • Học kỳ

Nếu mở rộng thêm Requirement, ta có thể bổ sung:

  • Lớp học phần
  • Khoa
  • Chương trình đào tạo
  • Giảng viên
  • Phiếu đăng ký

Đây là những ứng viên cho Domain Entity.

Lưu ý: Không phải mọi danh từ đều trở thành Entity. Hãy ưu tiên các đối tượng có ý nghĩa nghiệp vụ và cần được hệ thống quản lý lâu dài.

5. Thuộc tính của Entity

Sau khi xác định Entity, hãy mô tả những thông tin cần lưu trữ.

Ví dụ:

Sinh viên

  • Mã sinh viên
  • Họ tên
  • Ngày sinh
  • Email
  • Ngành học

Học phần

  • Mã học phần
  • Tên học phần
  • Số tín chỉ

Chỉ nên đưa vào những thuộc tính phục vụ nghiệp vụ.

Không nên thêm các thuộc tính kỹ thuật như:

  • created_at
  • updated_at
  • deleted_flag

Những thuộc tính này thuộc giai đoạn thiết kế hoặc triển khai.

6. Quan hệ giữa các Entity

Sau khi xác định Entity, hãy xem chúng liên hệ với nhau như thế nào.

Ví dụ:

  • Một sinh viên có thể đăng ký nhiều học phần.
  • Một học phần có nhiều sinh viên đăng ký.
  • Một lớp học phần do một giảng viên phụ trách.
  • Một học kỳ có nhiều lớp học phần.

Các quan hệ này giúp chúng ta hiểu cấu trúc của miền nghiệp vụ trước khi nghĩ đến thiết kế cơ sở dữ liệu.

7. Domain Model khác Class Diagram như thế nào?

Đây là nhầm lẫn phổ biến nhất.

Domain ModelClass Diagram
Mô tả miền nghiệp vụMô tả thiết kế phần mềm
Quan tâm khái niệm nghiệp vụQuan tâm cấu trúc lớp
Chỉ gồm Entity và quan hệCó thuộc tính, phương thức, kiểu dữ liệu, phạm vi truy cập
Dùng trong phân tíchDùng trong thiết kế

Có thể xem Domain Model là bản nháp khái niệm, còn Class Diagram là bản thiết kế kỹ thuật.

8. Ví dụ

Với hệ thống quản lý đào tạo.

Domain Model có thể gồm:

Sinh viên
↓
Đăng ký
↓
Lớp học phần
↓
Học phần
↓
Giảng viên

Từ mô hình này, chúng ta hiểu:

  • Sinh viên đăng ký lớp học phần.
  • Lớp học phần được mở cho một học phần.
  • Mỗi lớp học phần có giảng viên phụ trách.

Chưa cần quan tâm đến kiểu dữ liệu hay phương thức.

Sai lầm thường gặp

Đồng nhất Entity với bảng dữ liệu

Entity là khái niệm nghiệp vụ.

Bảng dữ liệu là cách hiện thực trong cơ sở dữ liệu.

Một Entity có thể ánh xạ thành một hoặc nhiều bảng.

Đồng nhất Domain Model với Class Diagram

Nếu mô hình bắt đầu xuất hiện:

  • getName()
  • setEmail()
  • private
  • public

thì bạn đã chuyển sang Class Diagram.

Đưa giao diện vào Domain Model

Ví dụ:

  • Form đăng nhập.
  • Màn hình báo cáo.

Đây không phải Entity.

Đưa các đối tượng kỹ thuật vào Domain

Ví dụ:

  • Database
  • API
  • Session
  • JWT Token

Đây là các thành phần kỹ thuật, không phải khái niệm của miền nghiệp vụ.

Tóm tắt

Domain Model giúp trả lời:

Hệ thống đang quản lý những đối tượng nào và chúng liên hệ với nhau ra sao?

Nó là cầu nối giữa phân tích nghiệp vụ và thiết kế hướng đối tượng.

Một Domain Model tốt sẽ:

  • Giúp các bên liên quan thống nhất ngôn ngữ nghiệp vụ.
  • Làm nền tảng cho Class Diagram.
  • Hỗ trợ thiết kế cơ sở dữ liệu.
  • Giảm rủi ro hiểu sai Requirement.

Hãy nhớ:

Đừng bắt đầu bằng Class Diagram. Hãy bắt đầu bằng Domain Model.

Deliverable

Từ hệ thống của bạn:

  1. Xác định tối thiểu 10 Domain Entity.
  2. Với mỗi Entity, liệt kê các thuộc tính chính.
  3. Xác định các quan hệ giữa các Entity.
  4. Kiểm tra xem mỗi Entity có xuất phát từ Requirement hoặc Use Case hay không.

Gợi ý bảng tổng hợp:

EntityThuộc tính chínhNguồn gốc (Requirement/Use Case)
Sinh viênMã SV, Họ tên, EmailĐăng ký học phần
Học phầnMã HP, Tên, Số tín chỉQuản lý học phần
Lớp học phầnMã lớp, Sĩ số, Lịch họcMở lớp học phần

Checklist

Sau khi học xong bài này, bạn nên trả lời được:

  • Domain là gì?
  • Domain Model dùng để làm gì?
  • Biết xác định Domain Entity từ Requirement và Use Case.
  • Phân biệt Domain Model với Class Diagram.
  • Xây dựng được Domain Model cho một hệ thống đơn giản.

Góc nhìn nghề nghiệp

Một trong những tư tưởng quan trọng của Domain-Driven Design (DDD) là: mô hình miền nghiệp vụ phải phản ánh đúng ngôn ngữ của chuyên gia nghiệp vụ (Ubiquitous Language). Điều đó có nghĩa là tên của các Entity, mối quan hệ và quy tắc nghiệp vụ nên được thống nhất giữa khách hàng, chuyên gia nghiệp vụ và nhóm phát triển.

Vì vậy, Domain Model không chỉ là một sơ đồ UML. Nó là từ điển chung của dự án, giúp mọi thành viên nói cùng một ngôn ngữ khi trao đổi về hệ thống. Một Domain Model rõ ràng sẽ làm cho Requirement dễ hiểu hơn, Class Diagram hợp lý hơn và mã nguồn phản ánh đúng nghiệp vụ hơn.

Bài tiếp theo

Đến đây, chúng ta đã xác định được các khái niệm và quan hệ trong miền nghiệp vụ.

Câu hỏi tiếp theo là:

Làm thế nào để chuyển các khái niệm đó thành các lớp phần mềm có thuộc tính, phương thức và mối quan hệ phục vụ cho việc lập trình?

Đó là nội dung của Bài 17 – Class Diagram, nơi chúng ta sẽ chuyển từ mô hình khái niệm (Conceptual Model) sang mô hình thiết kế (Design Model). Đây là bước kết nối trực tiếp giữa phân tích hệ thống và thiết kế hướng đối tượng, đồng thời là cơ sở để hiện thực hóa hệ thống bằng mã nguồn.

Comments are closed.

MENU