Một logic lọc nên có trong một kho lưu trữ hoặc trong một dịch vụ?

Tôi đang tự hỏi như sau: giả sử chúng ta đang xây dựng một hệ thống cần có một số chức năng lọc để tìm kiếm một thực thể nào đó. Ví dụ, người ta có thể muốn áp dụng bộ lọc cho bảng liệt kê các thực thể để tìm thứ gì đó hoặc sử dụng nó để tạo báo cáo trên bộ được lọc, bất cứ điều gì.

Vấn đề là: chúng ta cần phải có logic lọc ở đâu đó. Một cách tồi để làm điều này sẽ là sao chép logic lọc khi cần thiết. Tôi đã làm điều đó một lần và đó là một ý tưởng tồi tệ.

Mặt khác, tôi tin rằng nên có một phương thức như Filter(FilteringOptions filteringOptions)được thiết kế để thực hiện thao tác lọc và trả về danh sách các thực thể được lọc.

Bây giờ, IMHO, logic lọc là một logic kinh doanh loại. Các chuyên gia kinh doanh là những người biết cách lọc diễn ra, những gì được lọc và làm thế nào. Do đó, tôi tin rằng logic lọc nên được đặt trong lớp miền.

Tôi đã tìm thấy hai tùy chọn để thực hiện việc này: nhúng phương thức lọc vào kho lưu trữ tương ứng cho thực thể cụ thể đó, hoặc nếu không, tạo một dịch vụ miền giống như EntityNameSearchServicesẽ tiêu thụ kho lưu trữ để thực hiện lọc.

Tôi vẫn còn bối rối không biết cái nào sẽ là cách tốt hơn. Vậy, nếu tôi đang cố gắng sử dụng DDD đúng cách, thì logic lọc này sẽ ở đâu? Trên kho lưu trữ hoặc trong một dịch vụ riêng biệt?

Tôi đang tự hỏi như sau: giả sử chúng ta đang xây dựng một hệ thống cần có một số chức năng lọc để tìm kiếm một thực thể nào đó. Ví dụ, người ta có thể muốn áp dụng bộ lọc cho bảng liệt kê các thực thể để tìm thứ gì đó hoặc sử dụng nó để tạo báo cáo trên bộ được lọc, bất cứ điều gì.

Bạn nên quan sát rằng điểm này là các trường hợp sử dụng của bạn để lọc trung tâm xung quanh các lần đọc , thay vì ghi. Đây là mẫu bình thường - một ghi thường được gửi đến một gốc tổng hợp cụ thể trong miền của bạn.

Nếu bạn đang thực hiện đọc, thì bạn thực sự không quan tâm đến tổng hợp - bạn không quan tâm đến việc thực thi bất biến doanh nghiệp vì bạn thực sự không cố gắng thay đổi bất cứ điều gì. Bạn chỉ quan tâm đến nhà nước.

Điều đó có nghĩa là nó hoàn toàn hợp lý khi bỏ qua mô hình miền.

Chỉ cần một cái gì đó để suy nghĩ.

Bây giờ, IMHO, logic lọc là một logic kinh doanh loại. Các chuyên gia kinh doanh là những người biết cách lọc diễn ra, những gì được lọc và làm thế nào. Do đó, tôi tin rằng logic lọc nên được đặt trong lớp miền.

Có và không. Bạn đang sử dụng ngôn ngữ phổ biến để mô tả bộ lọc. Vì vậy, bạn chắc chắn đang sử dụng từ vựng tên miền.

Nhưng bạn không có bất kỳ "hành vi" nào, cho đến khi bạn không thực sự sửa đổi sổ ghi chép, vì vậy bạn không phải lo lắng về bất biến.

Mặt khác, tôi tin rằng nên có một phương thức như Filter (FilteringOptions filterOptions) được thiết kế để thực hiện thao tác lọc và trả về danh sách các thực thể được lọc.

Bạn rất gần với ý tưởng của "Đặc điểm kỹ thuật" . Về cơ bản, nó là một vị từ hơn một kho lưu trữ có thể sử dụng để xác định các tạo phẩm nào phù hợp với một số tiêu chí tùy ý.

Có một số bẫy cần lưu ý. Greg Young đã chạm vào họ một thời gian trước, nhưng tôi sẽ tóm tắt ở đây.

Đầu tiên, sự trừu tượng của việc chạy một vị từ đối với tập hợp là O (N). Bạn có thể muốn một cái gì đó đẹp hơn, đặc biệt nếu cửa hàng kiên trì của bạn thông minh về lập chỉ mục. Thành phần kiên trì của bạn có thể sẽ muốn có thể chuyển đổi nó thành một ràng buộc cụ thể thực hiện (ví dụ: lấy một đặc tả và biến nó thành một mệnh đề where trong một câu lệnh đã chuẩn bị).

Thứ hai, một giao diện là một phương tiện để ghi lại hợp đồng được phục vụ bởi thành phần kiên trì. "Làm cho ẩn rõ ràng" - nếu bạn mô tả những gì bạn thực sự cần, thì giao diện sẽ cho bạn biết một số đặc điểm quan trọng đối với cửa hàng dữ liệu của bạn, giúp bạn có một nơi để xem khi cố gắng đánh giá liệu có thay thế không cửa hàng phù hợp.

(Tất nhiên, việc triển khai giao diện đó có thể chỉ là một bộ điều hợp tạo ra đặc tả từ các đối số phương thức và chuyển tiếp theo đó. Điều đó ổn, bạn đã nắm bắt được yêu cầu thực tế).