Thiết kế điều khiển tên miền: Cách mô hình hóa các mối quan hệ lớn nhưng có ít hành vi

Question

Giả sử tôi có hai thực thể Người dùng và Mục. Hành vi duy nhất trong miền giữa hai thực thể này là người dùng có thể thích một mục. Vì không có giới hạn về số lượng mục mà người dùng có thể thích, mối quan hệ nhiều-nhiều này có thể lớn. Tôi không nghĩ rằng nó có ý nghĩa về mặt hiệu suất để Người dùng có chứa một danh sách các mục họ thích trong mô hình của nó hoặc theo cách khác, vì tôi sẽ phải tải một bộ sưu tập các mục có khả năng lớn để chỉ thêm một mục. Từ quan điểm thiết kế tên miền, nó cũng không có ý nghĩa với tôi để có một trong hai thực thể tham chiếu khác trong các lĩnh vực của họ như là không có hành vi yêu cầu sự hiện diện của một bộ sưu tập các mặt hàng hoặc người dùng.

Tôi cần giữ mối quan hệ này vì giao diện người dùng cần hiển thị danh sách các mục mà người dùng thích và danh sách người dùng thích một mục. Yêu cầu có thể được phục vụ bởi một mô hình đã đọc nhưng tôi vẫn cần một khái niệm miền để nắm bắt mối quan hệ này để nó có thể được duy trì. Một trong những cách tôi có thể đưa ra là giới thiệu một loại quan hệ tổng hợp, nói UserLikeItem, và có phương thức user.like (item) trả về một thể hiện của UserLikeItem mà sau đó tôi có thể sử dụng UserLikeItemRepository để tồn tại lâu dài.

Đây có phải là giải pháp hợp lệ không? Cách tự nhiên trong DDD để mô hình hóa loại quan hệ lớn nhưng không hành vi này là gì?

Answer 1

Tôi sẽ đào tại đây :), IMO nếu không có hành vi không tồn tại trong "mô hình miền" và nếu phần lớn các khái niệm của bạn không có hành vi thì bạn không cần " mô hình miền ", bạn có lẽ nên xem xét loại mẫu transaction script thay vì kiểu miền.

Tôi sẽ diễn giải câu hỏi của bạn thành "làm cách nào để duy trì nhiều mối quan hệ theo cách hiệu quả" cho câu hỏi này, chúng tôi có nhiều câu trả lời. các lớp học.

Mô hình miền và đại diện hướng đối tượng của phần phụ kiên trì là hai điều riêng biệt, mô hình miền là hành vi đầu tiên, vì vậy bạn nghĩ về hành vi và sau đó thêm thuộc tính vào mô hình miền sẽ bị ảnh hưởng bởi hành vi đó, khác những gì bạn cần là một "hướng đối tượng đại diện của sự kiên trì backend của bạn" (DTO)

nhưng nó được khéo léo khi bạn có trường hợp cho một mô hình miền, nhưng chỉ cần một vài khái niệm bị thiếu máu và thiếu vi nhưng thats một câu hỏi cho một ngày khác :)

Answer 2

'Thích' là thực tế miền, có thể được đại diện bởi Thực thể.
Các mục có Lượt thích -> Mục chứa bộ sưu tập Lượt thích.
Bộ sưu tập này là cần thiết chỉ để thêm và xoá thích -> hàng có tài sản LikeCount và thu Likes là tùy chọn cho truy vấn Repository (chỉ sử dụng trong Item.AddLikeFrom (user) và Item.RemoveLikeFrom (người sử dụng) phương pháp).

Nó có thể nhìn, mối quan hệ đó là phi hành vi, nhưng trên thực tế đó là hành vi của một trong những bên liên quan.

Answer 3

Kể từ khi tôi chạy vào kịch bản này một số thời gian trước đây, đây là quan điểm của tôi. tài và mục là một phần của cốt liệu khác nhau mà họ không biết/quan tâm đến nhau (thậm chí nếu một mục có một userId). Một "Giống như hệ thống" (LS) là một tổng hợp theo dõi khác nhau thích từ người để gì.

LS cũng không quan tâm đến người dùng hoặc mục, mặc dù vì tôi không thể thấy một trường hợp nào đó khác với người dùng có thể thích thứ gì đó, tôi có thể nói rằng Like sẽ luôn ngụ ý một userId (không phải toàn bộ khái niệm User) và một chủ đề (Item, VIdeo, Picture, Post, vv).

LS chỉ cần giữ liên kết Id người dùng và một mục khácId của một loại nhất định (có thể là một chuỗi, nếu bạn muốn LS không được kết hợp với Item là gì). Mỗi khi người dùng thích thứ gì đó mà lệnh được phát hành: RegisterLikeForItem {UserId, ItemId, ItemType}. Một trình xử lý LS sẽ lưu trữ thông tin đó rồi xuất bản sự kiện UserLikedItem. Một trong những trình xử lý của nó sẽ là bộ đếm sẽ đếm số lượng người dùng thích mục đó. Một trình xử lý khác có thể tạo danh sách các mục nào được một người dùng thích (điều này sẽ được truy vấn bởi giao diện người dùng).

Mỗi trình xử lý phục vụ một trường hợp sử dụng và có thể mỗi bộ nhớ đều có bộ nhớ riêng. Tôi biết nó trông khá phức tạp, nhưng nó thực sự đơn giản (một trường hợp sử dụng đòi hỏi một xử lý và có thể là một lưu trữ) và cược của tất cả, nó rất linh hoạt và duy trì. Và hệ thống hoạt động với một hoặc 1000 loại mục.