DDD - Kho lưu trữ gốc tổng hợp có xử lý lưu tập hợp không?


27

Tôi đang sử dụng cách tiếp cận giống DDD cho mô-đun trường xanh của ứng dụng hiện có; đó không phải là 100% DDD do kiến ​​trúc nhưng tôi đang cố gắng sử dụng một số khái niệm DDD. Tôi có một bối cảnh bị ràng buộc (tôi nghĩ đó là thuật ngữ phù hợp - tôi vẫn đang tìm hiểu về DDD) bao gồm hai Thực thể: ConversationMessage. Hội thoại là gốc, vì Tin nhắn không tồn tại mà không có cuộc hội thoại và tất cả các tin nhắn trong hệ thống là một phần của cuộc hội thoại.

Tôi có một ConversationRepositorylớp (mặc dù nó thực sự giống như Cổng, tôi sử dụng thuật ngữ "Kho lưu trữ") để tìm Cuộc trò chuyện trong cơ sở dữ liệu; khi tìm thấy Cuộc hội thoại, nó cũng tạo (thông qua các nhà máy) một danh sách các tin nhắn cho Cuộc hội thoại đó (được hiển thị dưới dạng một thuộc tính). Đây dường như là cách xử lý chính xác mọi thứ vì dường như không cần một MessageRepositorylớp toàn diện vì nó chỉ tồn tại khi lấy được Cuộc hội thoại.

Tuy nhiên, khi nói đến việc lưu Tin nhắn, đây có phải là trách nhiệm của ConversRep repository, vì đó là gốc tổng hợp của Tin nhắn? Ý tôi là, liệu tôi có nên sử dụng một phương thức trên ConversRep repository được gọi là AddMessagelấy Thông điệp làm tham số và lưu nó vào cơ sở dữ liệu không? Hoặc tôi nên có một kho lưu trữ riêng để tìm / lưu Tin nhắn? Điều hợp lý dường như là một kho lưu trữ trên mỗi Thực thể, nhưng tôi cũng đã nghe "Một kho lưu trữ cho mỗi bối cảnh".

Câu trả lời:


25

Các cuốn sách màu xanh chắc chắn là đáng đọc nếu bạn muốn để có được ra tốt nhất của cách tiếp cận DDD. Các mẫu DDD không tầm thường và việc tìm hiểu bản chất của từng mẫu sẽ giúp bạn suy ngẫm khi sử dụng mẫu nào, cách phân chia ứng dụng của bạn theo lớp, cách xác định Tổng hợp, v.v.

Nhóm 2 thực thể mà bạn đề cập không phải là Bối cảnh bị ràng buộc - đó có thể là một Tập hợp. Mỗi Tập hợp có một Tập hợp gốc, một Thực thể đóng vai trò là một điểm nhập duy nhất cho Tập hợp cho tất cả các đối tượng khác. Vì vậy, không có mối quan hệ trực tiếp giữa một Thực thể và một Thực thể khác trong một Tập hợp khác không phải là Tổng hợp gốc.

Các kho lưu trữ là cần thiết để có được các Thực thể không dễ dàng có được khi đi qua các đối tượng khác. Các kho lưu trữ thường chứa Rễ tổng hợp, nhưng cũng có thể có các kho lưu trữ của các thực thể thông thường.

Trong ví dụ của bạn, Hội thoại dường như là Tổng hợp gốc. Có thể Cuộc hội thoại là điểm bắt đầu của ứng dụng của bạn hoặc có thể bạn muốn truy vấn chúng với các tiêu chí chi tiết để chúng không thể truy cập một cách thỏa đáng thông qua việc duyệt qua các đối tượng khác. Trong trường hợp như vậy, bạn có thể tạo một Kho lưu trữ cho chúng để cung cấp cho mã máy khách ảo giác về một tập hợp các Cuộc trò chuyện trong bộ nhớ để truy vấn, thêm hoặc xóa trực tiếp. Mặt khác, tin nhắn có thể dễ dàng thu được bằng cách duyệt qua Cuộc hội thoại và bạn có thể không muốn nhận chúng theo tiêu chí chi tiết, chỉ cần tất cả Tin nhắn của Cuộc hội thoại cùng một lúc, vì vậy chúng có thể không cần Kho lưu trữ.

ConversRep repository sẽ đóng một vai trò trong các Tin nhắn vẫn tồn tại, nhưng không phải là vai trò trực tiếp như bạn đề cập. Vì vậy, không có AddMessage () trên ConversRep repository (phương thức đó thuộc về chính Hội thoại) mà thay vào đó, mỗi lần Kho lưu trữ sẽ duy trì Cuộc hội thoại, bạn nên duy trì Tin nhắn của mình cùng một lúc, trong suốt nếu bạn sử dụng khung ORM chẳng hạn như (N) Hibernate, sử dụng ad hoc SQL nếu bạn chọn như vậy, v.v.


1
Nếu một gốc tổng hợp, chẳng hạn như Hội thoại, có nhiều loại thực thể khác nhau trong đó, chẳng hạn như Tin nhắn, Điều, và Cánh, thì khi bạn lưu một cuộc hội thoại, ví dụ: ConversRepo.save (hội thoại), làm thế nào để bạn biết thực thể nào trong đó cần để được cứu? Trong ví dụ về áp phích ở trên, chỉ các thực thể thông báo cần được lưu. Bạn có duyệt qua tất cả các bộ sưu tập có thể trong gốc tổng hợp để tìm các thực thể không có id không?
chris-richards

3

Bạn có thể tạo Dịch vụ hội thoại và đưa IConversationRep repositoryIMessageRep repository vào hàm tạo của nó. Sử dụng kho lưu trữ cho các hoạt động CRUD đơn giản và dịch vụ cho mọi thứ khác (bộ nhớ đệm, lưu logic, v.v.)


1
không tiết kiệm logic CRUD?
Timothy Groote
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.