Domain Model được hiểu như thế nào?

Trong bài viết này, Tenten sẽ giải thích về Domain Model và các lớp liên quan đến nó. Hãy cùng đọc dưới đây:

Domain Model được hiểu như thế nào?

Domain Model là cách chúng ta hiểu về thế giới thực và những vấn đề mà ứng dụng của chúng ta cần giải quyết. Nó là một cách để thiết kế kiến trúc ở mức độ hệ thống chứ không chỉ mức độ lớp như MVC hay các design pattern khác. Ví dụ, bạn không thể xây dựng một hệ thống ngân hàng nếu không hiểu về ngành nghề ngân hàng. Thông thường, khi xây dựng một hệ thống, chúng ta có một thiết kế như psd, picture hoặc mô tả trong tệp tin, sau đó chúng ta phân tích và bắt đầu viết code. Domain Model là các lớp đại diện cho các lĩnh vực (domain), ví dụ như Client, Report, Department… Trong thực tế, các lớp đại diện cho kết quả tính toán hoặc các lớp làm tham số đầu vào cho dịch vụ tính toán được coi là Domain Model. Entity cũng là Domain Model, nhưng tương ứng với bảng trong cơ sở dữ liệu và có thể được ánh xạ vào cơ sở dữ liệu. Chú ý rằng chỉ có Entity mới đại diện cho dữ liệu trong cơ sở dữ liệu. Các loại dữ liệu khác có tên khác nhau, trừ Entity. Ví dụ, Entity User không có tên hậu tố, trong khi đối với Domain Model, chúng ta có thể có tên UserModel hoặc với DTO thì là UserDto…

Tuy nhiên, quá trình xây dựng Domain Model thì ngược lại, chúng ta phải đi từ lĩnh vực (domain), hay nói cách khác, đi từ tổng quát về nghiệp vụ của dự án sau đó mới đến phần thiết kế. Trong đó, ứng dụng được chia thành 4 lớp như sau: User Interface Layer: Đây là lớp biểu diễn thông tin trực quan cho người dùng và dịch các lệnh của người dùng. Ví dụ như những sự kiện xảy ra trên giao diện khi được kích hoạt sẽ được dịch thành các lệnh để xử lý ở các lớp dưới. Application Layer: Đây là lớp được thiết kế mỏng với ít logic xử lý, chỉ để điều phối các hoạt động của ứng dụng và không chứa logic kinh doanh. Nó không chứa trạng thái của các đối tượng kinh doanh mà chỉ chứa trạng thái của quá trình công việc của ứng dụng. Bạn có thể tưởng tượng phần này tương tự như các Controller trong kiến trúc MVC, chỉ đơn giản là điều phối các công việc đến nơi xử lý. Domain Layer: Đây là trái tim của ứng dụng (Phần mềm kinh doanh), nơi mà trạng thái của các đối tượng kinh doanh được lưu trữ. Việc lưu trữ đối tượng kinh doanh và trạng thái của chúng được giao cho lớp cơ sở hạ tầng ở lớp dưới. Trái tim của quá trình này nằm ở lớp Domain, nơi các nghiệp vụ được mô tả và cấu trúc mã nguồn được tổ chức theo tên các nghiệp vụ thay vì theo kiểu xem, điều khiển như truyền thống. Infrastructure Layer: Lớp này đóng vai trò thư viện hỗ trợ cho các lớp khác. Nó hỗ trợ cơ chế giao tiếp giữa các lớp với nhau, cũng như hỗ trợ các chức năng khác như lưu trữ đối tượng kinh doanh của lớp Domain model.

Xây dựng kiến thức về Domain Model

Để xây dựng kiến thức về Domain Model, bạn cần là người làm việc trực tiếp trong lĩnh vực đó, nhưng nếu bạn chỉ là người làm việc chuyên sâu trong lĩnh vực đó thì bạn không phải là lập trình viên nữa. Vấn đề là bạn cần ngồi và trò chuyện với những người có kinh nghiệm và kiến thức trong lĩnh vực đó. Ví dụ: Khi bạn muốn xây dựng hệ thống quản lý đường bay, chỉ những người trong ngành hàng không mới có đủ kiến thức, và mỗi khi họ đề cập đến một khái niệm mới, bạn liên tưởng ngay đến một đối tượng, thuộc tính hoặc phương thức trong lập trình. Bạn cũng liên tưởng đến cách thức một máy bay cất cánh, điều phối của từng lớp và cách mà một máy bay có thể bay từ địa điểm này đến địa điểm khác. Tuy nhiên, mỗi ngành nghề sẽ có những thuật ngữ khác nhau, để chuyển đổi thông tin mà những người trong ngành hàng không nói sang các thực thể trong lập trình, chúng ta cần có một ngôn ngữ chung hay còn gọi là Ngôn ngữ phổ biến (Ubiquitous language).

Ngôn ngữ phổ biến (Ubiquitous Language)

Ví dụ: Trong Domain Model của ngành nghề chuyển tiền, các chuyên gia sử dụng thuật ngữ “remittance”, và lập trình viên cũng phải sử dụng từ này để phản ánh trong mã nguồn của mình. “Remittance” trở thành một Ngôn ngữ phổ biến. Trong quá trình viết code, lập trình viên phải sử dụng Ngôn ngữ phổ biến trong mã nguồn của mình để khi người chuyên gia đọc có thể tưởng tượng ra được.

Entity

Nếu bạn đã từng làm việc với lập trình hướng đối tượng, bạn đã hiểu khái niệm về Đối tượng. Entity trong Domain Model thực chất là một đối tượng như vậy, nhưng nó có thêm thuộc tính là ID để xác định. Đơn giản hiểu theo ví dụ sau. Khi bạn là nhân viên của Sun*, bạn có thông tin được lưu trữ trên hệ thống wsm và có một mã nhân viên, tên và các thông tin khác. Trong Domain Model, khi bạn nghỉ công ty, mọi thông tin của bạn sẽ bị xóa. Như vậy, khái niệm nhân viên đó là một Entity.

Value object

Value Object cũng là một đối tượng, nhưng không cần xác định. Đặc tính của đối tượng là không thể thay đổi sau khi tạo ra. Một Value Object không có ý nghĩa nếu nó không được kết hợp với một Entity nào đó. Ví dụ: Bạn là một thực thể nhân viên, đôi khi bạn không cần quan tâm đến mã nhân viên của mình, nhưng công ty cần quan tâm để lưu trữ thông tin và trích xuất thông tin về bạn thông qua mã nhân viên. Mã nhân viên thực sự vô nghĩa nếu không được gán cho một nhân viên cụ thể, và đương nhiên mã nhân viên của bạn không thay đổi, phải không?

Tính tương đồng (Aggregate)

Đây là khái niệm trừu tượng, nhưng bạn có thể hiểu đơn giản rằng khi một đối tượng bị xóa, các đối tượng khác liên quan cũng bị xóa theo. Ví dụ, bạn có một bài viết trên Facebook, bài viết đó là một đối tượng post, một post có nhiều đối tượng comment và like. Nếu bạn xóa bài viết, các comment và like cũng sẽ bị xóa.

Kết luận

Đó là một số khái niệm quan trọng về Domain Model và các thông tin liên quan đến nó. Đây là một khái niệm phức tạp nhưng rất hữu ích trong quá trình xây dựng dự án. Hy vọng những chia sẻ này sẽ giúp ích cho chúng ta trong công việc hoặc đơn giản là sử dụng một phương pháp mới trong quá trình xây dựng dự án. Cảm ơn mọi người đã theo dõi.