1. Giới thiệu

Chào tất cả chúng ta, có lẽ dù bạn đang làm việc với ngôn ngữ lập trình nào, framework nào đi chăng nữa thì ít nhiều cũng đều từng làm việc với MVC, quy mô thiết kế cấu trúc project 3 lớp, ngày MVC ra đời và ai học hiểu được nó thì cảm thấy như hổ thêm cánh vậy, nó làm cho code của bạn gọn gàng dễ hiểu, dễ maintain hơn. Và không hề mờ nhạt theo thời gian, MVC vẫn theo chúng ta đến ngày nay và vẫn gần như giữ nguyên giá trị. Trong bài viết này mình không có ý khuyên chúng ta nên dùng parttern này hay pattern kia, mà chỉ giới thiệu đến chúng ta một pattern mà gần đây được đánh giá là khá hay, phù hợp cho những dự án to, đó là Domain Driven Design hay gọi tắt là DDD ,lần trước tiên được đưa ra bởi Eric Evans vào năm 2005.

Bạn đang xem: Domain model là gì

Bài Viết: Domain model là gì

2. Domain model là gì

Domain model là cách thức chúng ta hiểu biết 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, là cách thức thiết kế kiến trúc ở mức độ hệ thống chứ không phải mức độ class như MVC hay những design pattern khác. Ví dụ như bạn không thể xây dựng một hệ thống ngân hàng nếu bạn không có một chút hiểu biết gì về nghiệp vụ ngân hàng. Với cách thức làm thông thường khi xây dựng một hệ thống là chúng ta có có 1 bản thiết kế có thể là psd hay picture hay là một tệp tin spec, sau khi phân tích từ tệp tin design chúng ta xác định mình cần làm gì và bắt đầu code. Tuy nhiên với quy mô DDD lại ngược lại, chúng ta phải đi từ domain, hay nói cách thức khác là đi từ tổng quát nghiệp vụ của project sau đó mới đến phần design.Trong đó ứng dụng sẽ được phân thành 4 layer như sau:


*

User Interface Layer: làm nhiệm vụ biểu diễn thông tin trực quan cho user và dịch những user command ( ở đây chúng ta có thể hiểu là những sự kiện xảy ra trên giao diện khi được trigger ( nhấn nút trên những UI input control ) là những sẽ được dịch thành những command xử lý ở những tầng dưới.


Application Layer: Tầng này được thiết kế khá mỏng ( thin ) với ít logic xử lý chỉ để làm nhiệm vụ coordinate những Activity của Application và không chứa Business Logic, nó không chứa state của những Business Object mà chỉ chứa state của Application Task Progress. Chúng ta có thể tưởng tượng phần này gần giống với những Controller trong quy mô MVC chỉ làm nhiệm vụ forward những task đến nơi cần xử lý.

Domain Layer: Đây là trái tim của ứng dụng ( Business Software ), những state của Business Object đều tọa lạc ở đây. Việc lưu trữ ( persistence ) những Business Object và những state của nó được chuyển giao cho tầng Infrastructure ở dưới. Trái tim của quy mô này đó là ở phần Domain Layer, những nghiệp vụ sẽ được mô tả tại đây, và cấu trúc source code rất được tổ chức theo tên những nghiệp vụ chứ không để kiểu view, controller như truyền thống

Infrastructure Layer: Đóng vai trò đồng tình thư viện ( supporting libraries )cho những tầng khác. Nó đồng tình cơ chế tiếp xúc ( communication ) giữa những Layer với nhau, cũng như đồng tình những chức năng khác như lưu trữ ( persistence ) những Business Object của tầng Domain.

3. Xây dựng kiến thức domain

Để xây dựng kiến thức về domain bạn phải là người trực tiếp ở trong ngành nghề đó, nhưng nếu thế thì bạn lại không phải là coder nữa. Vấn đề là bạn cần ngồi xuống đàm đạo với những người liên quan có kinh nghiệm và kiến thức trong ngành nghề đó.


Ví dụ: Khi bạn muốn xây dựng hệ thống quản trị đường bay, rõ ràng là chỉ những người trong ngành hàng không mới đủ kiến thức, và mỗi khi họ nói về một khái niệm mới nào bạn liên tưởng ngay đến một object, properties hay method trong lập trình, cách thức máy bay cất cánh, đường bay như vậy nào làm bạn liên tưởng đếndriven cách thức điều phối của từng class cũng như cách thức mà một máy bay có thể bay từ địa điểm này đến địa điểm khác.

Xem thêm: Vì Sao Thủy Kính Tiên Sinh Là Ai, Thủy Kính Tiên Sinh Tư Mã Huy Có 8 Học

Tuy nhiên mỗi người một ngành nghề, để chuyển hóa từ thông tin mà những người trong ngành hàng không nói sang những thực thể trong lập trình chúng ta cần phải có một ngôn ngữ chung hay còn gọi là Ubiquitous language.

4. Ubiquitous Language


*

Ví dụ về nghiệp vụ chuyển tiền thì domain expert sử dụng từ remittance, thì anh dev cũng phải sử dụng từ khóa này phản ánh trong source code của tôi. Remittance trở thành 1 Ubiquitous language.Tóm lại khi code, developer phải thể hiện Ubiquitous language trong source code của tôi để domain expert khi đọc có thể tưởng tượng ra được.

5. Entity


*

Nếu bạn hay lập trình hướng đối tượng người dùng thì sẽ hiểu rõ khái niệm về Object. Entity trong DDD thực chất là một object như vậy, tuy vậy nó lại thêm 1 thuộc tính là ID để định danh. Hiểu đơn giản theo ví dụ sau. Khi bạn là nhân viên của Sun* bạn sẽ có thông tin trên hệ thống wsm và có mã nhân viên B****** , tên tuổi vv.. và khi bạn nghỉ công ty thì mọi thông tin của bạn sẽ bị xóa khỏi. Như vậy khái niệm nhân viên đó là 1 Entity.

6. Value object

Value Object thức chất vẫn là 1 Object nhưng không cần định danh. Đặc tính của object là Immutable, tạo ra rồi thì không thể thay đổi được. Một value object sẽ không có ý nghĩa gì nếu không được tích hợp một entity nào đó.


Ví dụ: bạn là một thực thể nhân viên, rõ ràng thỉnh thoảng bạn không cần phải quan tâm mã nhân viên của tôi, nhưng công ty lại quan tâm để lưu trữ thông tin và trích xuất thông tin về bạn trải qua mã nhân viên, và mã nhân viên ấy thực sự vô nghĩa nếu không được gán vào một nhân viên cụ thể, ở đây đó là bạn. Và đương nhiên mã nhân viên của bạn thì không thay đổi đúng không nào.

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

Khá là trừu tượng, tuy vậy bạn cũng có thể hiểu đơn gian đó là khi một thực thể bị xóa khỏi nó sẽ bị kéo theo xóa khỏi những thực thể khác. Chẳng hạn bạn có 1 bài viết trên FB, bài post ấy là 1 entity post, một post lại có rất nhiều entity comment và entity like, nếu bạn xóa bài post ấy đi thì kéo theo comment và like cũng bị xóa khỏi.

8. Kết luận

Trên đây là một số khái niệm quan trọng trong DDD, đây thực sự là một quy mô rất hay nhưng lại khó tiếp cận vì quá khó hiểu, mình cũng đang trong quá trình tìm hiểu cũng như nỗ lực dùng nó trong một dự án gần nhất. Hy vọng những san sẻ này sẽ giúp ích cho chúng ta trong quá trình làm việc hay đơn giản chỉ là dùng một quy mô mới trong quá trình xây dựng dự án. Cảm ơn mọi người đã theo dõi


*

Thể Loại: Chia sẻ Kiến Thức Cộng Đồng
Bài Viết: Domain Model Là Gì – What Is Domain Driven Design

Thể Loại: LÀ GÌ

Nguồn Blog là gì: https://kulturbench.com Domain Model Là Gì – What Is Domain Driven Design

Bài viết liên quan

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *