tuananhhedspibk / ddd-modeling Goto Github PK

Khi ghi chép để biểu thị các Aggregate (kết tập), ta cần thể hiện được mối liên hệ giữa các objects, do đó việc phân biệt các object ở trong / ngoài kết tập là rất quan trọng do chúng sẽ có cách biểu thị khác nhau.

• Trong cùng một kết tập thì ta sẽ dùng kí hiệu composition để trỏ đến object được tham chiếu
• Khác kết tập thì ta sẽ dùng kí hiệu association để trỏ đến object được tham chiếu

Lưu ý: 2 kí hiệu association, composition đều là kí hiệu dùng trong UML. (Ref: tuananhhedspibk/TeckStack#95)

Về bản chất đây là sơ đồ được đơn giản hoá từ sơ đồ class. Nó sẽ chứa các yếu tố sau:

• Các properties tiêu biểu của object, không nhất thiết phải viết ra các methods
• Ghi rõ các rules cũng như business logic
• Biểu thị tính liên quan giữa các objects
• Định nghĩa tính đa dạng
• Định nghĩa phạm vi của Aggregate
• Ghi ví dụ cụ thể để dễ hình dung

Sau khi thiết kế Aggregate xong ta có thể quyết định cách thiết kế cũng như triển khai các Repositories.

Bất kể với sơ đồ use-case hay sơ đồ domain model thì khi tiến hành trao đổi ý kiến với các thành viên khác trong team, ta đều nên viết ra white board để mọi người có thể cùng nhau trao đổi ý kiến và hoàn thành các sơ đồ trên.

Với sơ đồ use-case về ứng dụng quản lí task, ta có thể đưa ra sơ đồ domain model như sau:

Ta có thể thấy rằng 1 user có thể có 0..n task và cũng có thể thấy được các rules khi khởi tạo hoặc thay đổi user, task.

Nên cân nhắc những gì cần thiết phải đưa vào model cũng như những gì không cần thiết phải đưa vào model.

Ta lấy ví dụ với model Resume, ta cần đưa vào nó những thông tin quan trọng sau đây:

• Tên
• Quá trình làm việc / công tác
• Lí do apply
• Ảnh mặt

Còn những yếu tố dưới đây được coi là những yếu tố không quan trọng:

• Chữ kí
• Resume maker
• Cảm xúc khi viết Resume

Nếu model và software triển khai nó có một sự khác biệt đáng kể thì việc giải quyết vấn đề (vốn dĩ là nhiệm vụ chính của model) sẽ ngày một khó hơn.

Không những thế, việc đọc code để hiểu được model cũng trở nên khó khăn hơn.

Do đó hãy giữ cho code và model ở "gần nhau" nhất có thể, và cũng vì lí do này mà DDD hỗ trợ OOP rất mạnh.

Là sơ đồ mô tả các hành động của hệ thống nhằm đáp ứng yêu cầu từ phía người dùng.
Lấy ví dụ với ứng dụng quản lí task, ta sẽ có sơ đồ usecase như sau:

Sơ đồ use-case sẽ được tạo ra trước sơ đồ domain model. Vậy tại sao ta lại cần sơ đồ use-case. Sau đây là lí do:

• Nếu ta không rõ được các use-cases thì việc thiết kế model sẽ trở nên khó khăn. Ở ví dụ trên nếu đứng ở góc độ của người làm việc thì quá trình quản lí task sẽ khác so với góc độ quản lí task của người quản lí (manager)

Ngoài ra ta cũng cần phải quyết định scope của sơ đồ domain model, lí dó là vì nếu không quyết định scope của domain model thì có thể dẫn tới tình trạng phạm vi của vấn đề sẽ trở nên quá rộng và quá trình thiết kế domain model sẽ không đem lại hiệu quả gì cả.

Khi bắt đầu ta có thể bắt đầu domain model với scope nhỏ, sau đó ta sẽ dần dần scale scope của nó lên cũng được. Khi đó ta cũng cần phải scale scope của sơ đồ use-case lên để tạo sự đồng bộ.

Ta có thể thấy những thiết kế rất tốt với:

• Entity
• Repository
  những thiết kế này được gọi là Light DDD, thế nhưng nếu chúng không giúp software giải quyết được những bài toàn trong thực tế thì cũng không có ý nghĩa gì cả.

Thế nên trong thực tế hãy áp dụng:

• Các pattern thiết kế
• Modeling
  cùng nhau để dần dần cải thiện thiết kế của bạn nhằm mục đích giúp software giải quyết được một vấn đề trong thực tế.

Việc tạo ra một model hoàn chỉnh ngay từ đầu là chuyện không thể. Do đó hãy tiến hành vòng tuần hoàn sau:

MODELING → TRY → FIX

Cho đến khi bạn tìm ra được một model ưng ý nhất cho mình. Hơn nữa nếu bạn cần phải đưa ra một thiết kế áp dụng cho nhiều ứng dụng cùng một lúc thì điều này là một điều vô cùng khó và dễ gây chán nản, hãy bắt đầu từ một phần nhỏ trong ứng dụng. Sau khi cảm thấy ổn hãy scale dần lên.

Domain là lĩnh vực mà phần mềm sẽ giải quyết một vấn đề của nó.
Model là một hệ thống các abstractions mô tả một khía cạnh của domain và có thể được sử dụng để giải quyết vấn đề liên quan đến domain đó.
Modeling là quá trình tạo ra một model.
Domain Model: là model dùng để giải quyết vấn đề của domain.
Data model: là model dùng để giải quyết vấn đề liên quan đến việc lưu trữ dữ liệu.

Các xử lí giao tiếp với UI và DB không nên "được trộn lẫn" vào phần code của model. Lí do là vì khi đó:

• Lượng code của model sẽ tăng lên rất nhiều
• Giảm đi tính đọc hiểu của code
• Giảm đi tính bảo trì của code

Do đó các xử lí liên quan đến UI hay DB, ... và code của model nên được phân chia thành các tầng riêng biệt. Tầng đảm nhiệm model được gọi là tầng domain.

Về cơ bản ta sẽ thấy 3 loại kiến trúc sau thường xuất hiện trong thực tế:

• Layer Architecture
• Onion Architecture
• Clean Architecture

Với các rules hay business logic thì khi ta có ý tưởng hay một sáng kiến nào đó về chúng, hãy viết ra dưới dạng các gạch đầu dòng.

Tiêu biểu ở đây ta có thể viết dưới dạng sơ đồ chuyển trạng thái. Trình bày dưới dạng sơ đồ sẽ dễ hiểu hơn so với viết chữ rất nhiều. Với những trường hợp như vậy ta có thể kết hợp giữa sơ đồ chuyển trạng thái với sơ đồ domain model.