Là tổng hợp gốc với phân cấp sâu thích hợp trong DDD?

Question

Tôi có một hệ thống nơi người dùng trả lời câu hỏi trong biểu mẫu. Tôi có các đối tượng đại diện cho mô hình này nhưng tôi không hoàn toàn chắc chắn làm thế nào để tổ chức các đối tượng này về DDD.

1. Biểu mẫu (có danh sách riêng) Phần;
2. Phần -> (có danh sách riêng) Nhóm;
3. Nhóm -> (có danh sách riêng) Câu hỏi;
4. Câu hỏi -> (có thể có danh sách câu hỏi phụ riêng) Câu hỏi;
5. Câu hỏi -> (có danh sách riêng) Các câu trả lời;
6. Trả lời -> (có danh sách riêng) Answer_Details;
7. Answer_Detail -> (có thể có danh sách chi tiết phụ riêng) Sub_Answer_Details.

Mỗi đối tượng có hơn 15 thuộc tính và mỗi đối tượng không có ý nghĩa nếu không có cha mẹ. Theo DDD, tôi tin rằng thực thể Form nên là một gốc tổng hợp và tất cả các đối tượng khác nên là đối tượng giá trị. Điều đó có nghĩa là tôi chỉ cần một Kho lưu trữ cho thực thể Biểu mẫu. Trong trường hợp này FormRepository sẽ được lộn xộn với tất cả các loại phương pháp CRUD cho các đối tượng con. Quyền lý luận của tôi có phải là DDD không? Liệu có ổn không khi tôi kết thúc với một tập hợp rất rộng lớn? Tôi tin rằng đại diện như vậy có thể dễ dàng dẫn đến các vấn đề hiệu suất.

Answer 1

Có, phân cấp sâu là tốt trong DDD.

OK có phải là kết thúc với một tập hợp rất rộng lớn không? - nếu thực tế là phức tạp, và mô hình miền của bạn là tốt nhất như bạn có thể tìm ra, bạn sẽ kết thúc với một gốc tổng hợp phức tạp.

Yep, Form phải là gốc tổng hợp.

tất cả các đối tượng khác phải là đối tượng giá trị - sai, tất cả các đối tượng khác phải là thực thể gốc không tổng hợp (có Id) không có kho để tìm nạp chúng. Đối tượng giá trị không có Id và bình đẳng của các đối tượng giá trị được xác định chỉ bởi các giá trị thuộc tính của nó, không phải bằng tính bình đẳng của các Id (thông tin thêm here).

Trong trường hợp này FormRepository sẽ được lộn xộn với tất cả các loại phương pháp CRUD cho các đối tượng trẻ - không, một kho lưu trữ nên chỉ chứa các phương pháp liên quan đến gốc tổng hợp, tức là Get<T> , Save<T> where T : IAggregateRoot, một khi bạn có được một thể hiện của một gốc tổng hợp, bạn có thể đi qua các thuộc tính và phương pháp để có được những gì bạn cần.Ví dụ:

var formId = 23; 
var form = _formRepository.Get(formId); 
var firstGroup = form.Sections.First().Group().First(); 

hoặc tốt hơn

var groupIndex = 1; 
var firstGroup = form.GetGroupAt(groupIndex); 

nơi

public Group GetGroupAt(int groupIndex) 
{ 
    Sections.First().Group().ElementAt(groupIndex); 
} 

Tôi tin rằng đại diện như vậy có thể dễ dàng dẫn đến hiệu suất phát - nếu bạn sử dụng CQRS, bạn sẽ được kêu gọi một số Form phương pháp miền từ trình xử lý lệnh và nếu bạn sử dụng NHibernate cho đối tượng persistence, nó sẽ bằng defaul t sử dụng tải chậm và chỉ tải Form từ DB và sau đó nó sẽ chỉ tải các thực thể bạn thực sự chạm vào, ví dụ: Sections.First() sẽ tải tất cả các phần từ DB chứ không phải các nhóm và phần còn lại. Đối với truy vấn, bạn sẽ tạo một đối tượng chuyển dữ liệu FormDto và các dtos khác có thể để lấy dữ liệu dưới dạng bạn cần (có thể khác với cấu trúc thực thể và giao diện người dùng có thể thúc đẩy cấu trúc dto). Có một cái nhìn tại blog tôi để biết về DDD/CQRS/NHibernate/Repository

Answer 2

Mặc dù một câu trả lời đã được chấp nhận tôi nghĩ rằng tôi cũng có thể thêm tôi 2 cent:

phân cấp sâu là (có thể) tốt nhưng hãy nhớ rằng ý tưởng đằng sau tổng hợp là thực sự ngăn chặn điều này. Tôi có xu hướng nghĩ về thực thể trong một tổng hợp dọc theo dòng:

"Liệu thực thể này có bất kỳ ý nghĩa mà không AR?"

Vì tôi không có bất kỳ ngữ cảnh nào.r.t. mô hình của bạn, tôi sẽ sử dụng Order/OrderLine. Có phải OrderLine có bất kỳ ý nghĩa nào nếu không có Order không? Tôi có thể làm bất cứ điều gì (hành vi) với dòng lệnh của chính nó? Câu trả lời rõ ràng ở đây là "không".

Mỗi mô hình sẽ cần phải được xử lý dựa trên ngữ cảnh. Nhưng quyền sở hữu không nhất thiết có nghĩa là ngăn chặn.

Đây có thể được dễ dàng hơn để xem khi bạn làm việc với bối cảnh bị chặn riêng một cung cấp được các BCs sửa :)

Trong trường hợp của bạn một Answer có thể không có ý nghĩa mà không Question của nó. Nhưng có thể một số Question có thể sống ở số QuestionBank trước Công nguyên và câu hỏi cụ thể có thể được sử dụng trong cả số Examination BC và Enrollment BC của bạn. Tất cả những điều này hoàn toàn được tạo nên để nó phụ thuộc vào ngữ cảnh của bạn.

Vì vậy, nếu trường hợp đó là Question có thể là AR thì câu hỏi thuộc sở hữu của bạn Form AR có thể chỉ đơn giản là một đối tượng giá trị hoặc thậm chí là một câu hỏi đơn giản.