DDD: Mọi thứ có vừa với Entity hoặc Value Object không?

Question

Tôi đang cố gắng theo dõi DDD, hoặc ít nhất là sự hiểu biết hạn chế của tôi về nó.

Tôi đang gặp sự cố khi lắp một vài thứ vào hộp DDD.

Ví dụ: Tôi có Pháp nhân người dùng. Entity người dùng này có một tham chiếu đến một đối tượng UserPreferencesInfo - đây chỉ là một lớp có chứa một loạt các thuộc tính liên quan đến các tùy chọn của người dùng. Các thuộc tính này khá không liên quan, khác với thực tế là chúng đều là sở thích của người dùng (không giống như nói một địa chỉ VO, nơi tất cả các thuộc tính tạo thành một toàn bộ có ý nghĩa).

Câu hỏi là - đối tượng UserPreferencesInfo này là gì?

1) Rõ ràng nó không phải là một thực thể (Tôi chỉ lưu trữ nó là 'thành phần' trong speak nhibernate thạo (ví dụ: trong cùng một bảng DB là đơn vị thành viên).

2) VO? Tôi hiểu rằng Value Object được coi là Không thể thay đổi (vì vậy bạn không thể cange chúng, chỉ cần mới chúng lên). Điều này làm cho cảm giác hoàn toàn khi đối tượng là một địa chỉ ví dụ (các thuộc tính địa chỉ tạo thành một 'toàn bộ' có ý nghĩa). Nhưng trong trường hợp UserPreferencesInfo tôi không nghĩ rằng nó có ý nghĩa. Có thể có 100 thuộc tính (Thực tế) Có thể có 20 thuộc tính trên đối tượng này - tại sao tôi muốn loại bỏ một đối tượng tái tạo bất cứ khi nào tôi cần thay đổi một thuộc tính?

Tôi cảm thấy như tôi cần phải phá vỡ các quy tắc ở đây để có được những gì tôi cần, nhưng tôi không thực sự thích ý tưởng đó (đó là một dốc trơn!). Am i thiếu cái gì ở đây?

Cảm ơn

Answer 1

Theo như tôi hiểu, UserPreferenceInfo là một phần của User thực thể. Thực thể người dùng Ergo là một gốc tổng hợp được lấy ra hoặc lưu lại bằng cách sử dụng UserRepository nói chung, cùng với UserPreferenceInfo và các đối tượng khác.

Cá nhân, tôi nghĩ rằng UserPreferenceInfo là loại thực thể, vì nó có danh tính - nó có thể được thay đổi, lưu và lấy từ kho và vẫn được coi là cùng một đối tượng (tức là có nhận dạng). Nhưng nó phụ thuộc vào cách bạn sử dụng nó.

IMO không quan trọng đối tượng được thể hiện như thế nào trong DAL - là nó được lưu trữ trong một bảng riêng biệt hoặc một phần của bảng khác. Một trong những lợi ích của DDD là sự thiếu hiểu biết và là một điều tốt.

Tất nhiên, tôi có thể sai, tôi cũng mới với DDD.

Answer 2

100 thuộc tính có vẻ như rất nhiều.

Hãy thử chia nhỏ UserPreferenceInfo thành các loại nhỏ hơn (gắn kết hơn), có khả năng/hy vọng là có thể quản lý dưới dạng VO.

Answer 3

Tôi muốn nói UserPreferenceInfo thực sự là một phần của gốc Tổng hợp người dùng. Nó sẽ là trách nhiệm của UserRepository để duy trì User Aggregate Root.

Đối tượng giá trị chỉ cần được làm mới (trong mô hình đối tượng) khi giá trị của chúng được chia sẻ. Một kịch bản mẫu cho điều đó sẽ là nếu bạn kiểm tra một UserPreferenceInfo tương tự và liên kết Người dùng với điều đó thay vì Chèn một cái mới mỗi lần. Chia sẻ các đối tượng Value có ý nghĩa nếu các bảng đối tượng giá trị sẽ nhận được lớn và tăng các mối quan tâm về tốc độ/lưu trữ. Giá chia sẻ được thanh toán trên Chèn. Đó là hợp lý để trừu tượng thủ tục này trong DAL.

Nếu bạn không làm lung lay các đối tượng giá trị, không có gì chống lại việc cập nhật.

Answer 4

Đây là hai xu của tôi. Câu trả lời ngắn: UserPreferenceInfo là một đối tượng giá trị vì nó mô tả các đặc tính của một đối tượng. Nó không phải là một thực thể bởi vì không cần phải theo dõi một thể hiện đối tượng theo thời gian.

Câu trả lời dài hơn: đối tượng có hơn 100 thuộc tính không liên quan không phải là DDD-ish. Cố gắng nhóm các thuộc tính liên quan lại với nhau để tạo thành VO mới hoặc bạn cũng có thể khám phá các thực thể mới.

Một mùi DDD khác là có nhiều thuộc tính được đặt ở vị trí đầu tiên. Cố gắng tìm bản chất của hành động thay vì chỉ đặt giá trị. Ví dụ:

// not ddd 
employee.Salary = newSalary; 

// more ddd 
employee.GiveRaise(newSalary); 

Mặt khác, bạn có thể có lý do chính đáng để có nhiều thuộc tính không hơn getters và setters. Nhưng sau đó có thể có phương pháp đơn giản hơn DDD để giải quyết vấn đề. Không có gì sai khi lấy các mẫu và ý tưởng tốt nhất từ ​​DDD nhưng thư giãn một chút trong tất cả các "quy tắc", đặc biệt là cho các miền đơn giản hơn.

Answer 5

Câu hỏi - đối tượng UserPreferencesInfo này là gì?

Tôi không biết trường hợp này được NHibernate hỗ trợ như thế nào, nhưng một số ORM hỗ trợ các khái niệm đặc biệt cho chúng. Ví dụ: DataObjects.Net bao gồm khái niệm Structures. Có vẻ như bạn cần một cái gì đó như thế này trong NH.

Answer 6

Trả lời 1 (một trong những thực tế)

Tôi là một người ủng hộ rất lớn của DDD, nhưng không buộc nó. Bạn đã nhận ra rằng VO bất biến thêm nhiều công việc hơn là bắt buộc. DDD được thiết kế để khai thác sự phức tạp, nhưng trong trường hợp này có rất ít phức tạp để quản lý.

Tôi chỉ đơn giản là coi UserPreferencesInfo là Thực thể và tham chiếu từ tổng hợp User. Cho dù bạn lưu trữ nó như là một thành phần hoặc trong một bảng riêng biệt là sự lựa chọn của bạn.

IMHO, toàn bộ cuộc tranh luận Entity vs. VO có thể được hiển thị. Rất khó xảy ra trong thời gian 6 tháng, một nhà phát triển khác sẽ xem mã của bạn và nói "WTF! Anh ấy không sử dụng VO bất biến! Anh ấy đang nghĩ cái quái gì vậy !!".

trả lời 2 (purist DDD)

là UserPreferencesInfo thực sự là một phần của lĩnh vực kinh doanh? Những người khác đã đề cập đến việc phân biệt đối tượng này. Nhưng nếu bạn gắn bó với DDD thuần túy, bạn có thể cần xác định tùy chọn nào thuộc về Ngữ cảnh bị ràng buộc.

này đến lượt nó có thể dẫn đến thêm Layers Dịch vụ, và trước khi bạn biết điều đó, bạn đã qua chế là giải pháp cho một vấn đề rất đơn giản ...

Answer 7

Lần đầu tiên bao giờ đăng trên một blog. Hy vọng tôi làm điều đó đúng.

Dù sao, vì bạn chưa cho chúng tôi thấy đối tượng UserPreferencesInfo, tôi không chắc nó được xây dựng như thế nào để bạn có thể có số lượng thay đổi trong đó.

Nếu là tôi, tôi sẽ tạo một lớp duy nhất có tên là UserPreference, với id, userid, key, value, displaytype và bất kỳ trường nào khác bạn có thể cần trong đó. Đây là một thực thể. nó có một id và được gắn với một người dùng nào đó.

Sau đó, trong thực thể người dùng của bạn (gốc tôi giả định), có một ISet.