Domain Model Là Gì – What Is Domain Driven Design

Related Articles

1. Giới thiệu

Chào tất cả các bạn, 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, mô hình 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 các bạn nên dùng parttern này hay pattern kia, mà chỉ giới thiệu đến các bạn một pattern mà gần đây được đánh giá là khá hay, phù hợp cho những dự án lớn, đó là Domain Driven Design hay gọi tắt là DDD ,lần đầu tiên được đưa ra bởi Eric Evans vào năm 2005.

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

2. Domain model là gì2. Domain model là gì

Domain model là cách chúng ta hiểu biết về thế giới thực và những vấn đề mà phần mềm của chúng ta cần giải quyết, là cách 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 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 file spec, sau khi phân tích từ file design chúng ta xác định mình cần làm gì và bắt đầu code. Tuy nhiên với mô hình DDD lại ngược lại, chúng ta phải đi từ domain, hay nói cách 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 chia 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 các user command ( ở đây chúng ta có thể hiểu là các event xảy ra trên giao diện khi được trigger ( nhấn nút trên các UI input control ) là các sẽ được dịch thành các command xử lý ở các 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 các Activity của Application và không chứa Business Logic, nó không chứa state của các Business Object mà chỉ chứa state của Application Task Progress. Chúng ta có thể hình dung phần này gần giống với các Controller trong mô hình MVC chỉ làm nhiệm vụ forward các task đến nơi cần xử lý.

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

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

3. Xây dựng kiến thức domain3. Xây dựng kỹ năng và kiến thức domainĐể kiến thiết xây dựng kiến thức và kỹ năng về domain bạn phải là người trực tiếp ở trong nghành đó, 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 bàn luận với những người tương quan có kinh nghiệm tay nghề và kiến thức và kỹ năng trong nghành đó .

Ví dụ: Khi bạn muốn xây dựng hệ thống quản lý đườ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 máy bay cất cánh, đường bay như thế nào làm bạn liên tưởng đếndriven cách điều hướng của từng class cũng như cách mà một máy bay có thể bay từ địa điểm này đến địa điểm khác.

Xem thêm: Sink Là Gì

Tuy nhiên mỗi người một nghành nghề dịch vụ, để 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 tất cả chúng ta cần có một ngôn từ chung hay còn gọi là Ubiquitous language .4. Ubiquitous Language

4. Ubiquitous Language

*Ví dụ về nhiệm 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 mình. Remittance trở thành 1 Ubiquitous language. Tóm lại khi code, developer phải biểu lộ Ubiquitous language trong source code của mình để domain expert khi đọc hoàn toàn có thể tưởng tượng ra được .5. Entity5. 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 ra là một object như vậy, tuy nhiên nó có thêm 1 thuộc tính là ID để định danh. Hiểu đơn thuần theo ví dụ sau. Khi bạn là nhân viên cấp dưới của Sun * bạn sẽ có thông tin trên mạng lưới hệ thống wsm và có mã nhân viên cấp dưới 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 bỏ. Như vậy khái niệm nhân viên cấp dưới chính là 1 Entity .6. Value object6. Value objectValue 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 hề đổi khác được. Một value object sẽ không có ý nghĩa gì nếu không được gắn vào một entity nào đó .

Ví dụ: bạn là một thực thể nhân viên, rõ ràng bình thường bạn không cần phải quan tâm mã nhân viên của mình, 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 thông 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 chính 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.

Xem thêm: Fix: Intel Rst Service Is Not Running, Khắc Phục: Dịch Vụ Intel Rst Không Hoạt Động

7. Tính đồng bộ (Aggregate)7. Tính đồng nhất ( Aggregate )

Khá là trừu tượng, tuy nhiên bạn có thể hiểu đơn gian đó là khi một thực thể bị xóa bỏ nó sẽ kéo theo xóa bỏ những thực thể khác. Chẳng hạn bạn có 1 bài viết trên facebook, 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 bỏ.

8. Kết luận8. Kết luậnTrên đây là 1 số ít 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 quy trình tìm hiểu và khám phá cũng như nỗ lực vận dụng nó trong một dự án Bất Động Sản gần nhất. Hy vọng những san sẻ này sẽ giúp ích cho những bạn trong quy trình thao tác hay đơn thuần chỉ là vận dụng một quy mô mới trong quy trình thiết kế xây dựng dự án Bất Động Sản. Cảm ơn mọi người đã theo dõi*

Chuyên mục: Chuyên mục : Hỏi Đáp

More on this topic

Comments

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Advertismentspot_img

Popular stories