Non CRUD operations in Domain Service

I have a domain service related to "invoice" data. Invoice has multiple fields - invoice items, invoice status etc. Each invoice item has some fields like - invoice item status, purchase order id, item identifier, quantity. Invoice and invoice items are stored in separate tables which my domain service interacts with.

There is an existing separate search service as well for searching invoice and invoice items.

The internal client's use-case is to find the total quantity for list of (purchase order id, item identifier) pairs. This also includes some business logic, for instance, considering only those invoice and invoice items which don't have status as CANCELLED.

I have considered the below approaches:

1. Expose an API in my domain service which will provide this capability. At service end, this is a simple sum query to get the total quantity. This has the benefit that business logic will remain at domain service end.

2. Let the client do the sum at its end after it uses the search invoice item method of search service. Now this will expose the business logic at client's (even though its internal) end.

3. Consider adding an application layer in between and apply business logic there. this layer can either use domain service or search service to fetch the invoice items first.

My question is to understand if it is an anti-pattern to provide such method (that does the sum of a particular field) at domain service end. What is the recommended way to provide such functionality?