I know you've already accepted an answer, but, you asked about DDD, and the exact match for this is what Evans calls a 'specification':
direct google books link
If that link doesn't work check for the book in these results
It's page 226 if you have the book.
On page 227 are 3 uses for specifications: Validation, Seletion, Building a new special object. Yours is 'selection' - IsExpired.
Another thing about the 'specificaiton' concept is that it admits that - for efficiency's sake - you may need one version of code to operate on the in-memory objects, and another version of the code to efficiently query the repository without having to first get all the objects into memory.
In a simple world, this would mean putting a SQL version in your repository and an objects version in your model, of course that has drawbacks. The logic is in 2 places (bad, somebody's going to forget to update on of those places) and there is domain logic in your repository.
So the answer is to put both sets of logic in a specification. The in-memory version, obviously, but a repository version, too. If you are using for example n-hibernate you can use its built-in query language for the repository version.
Otherwise you'll have to create a special repository method for this specification that is used from the specification object. Calls for collecitons of objects matching the specification would go thru the specification, not the repository. And at least the code screams 'i'm in 2 places, don't forget it' to future maintainers. There is a wonderful example on page 231-232 for a solving very similar problem.
The specification is an 'allowed' leakage/slippage of the 'purity' of DDD. It still might not serve your needs for a variety of purposes. For example, the ORM might generate bad SQL; there might be too much extra coding. So you might have to call repository methods such that it's almost like putting SQL in the specification. A bad thing of course. But don't forget, your program has to work- at a reasonable speed. It doesn't have to win a DDD purity prize. So a reality of switching datastores might mean old fashioned surgury thoughout the program. Also a bad thing. But not as bad as a slow (aka SUCKing) program. If running out of the box on various DBs is a reality, obviously, you'll be duplicating business rules for each datastore for each specification. At least you have your finger on the matter and you can make use of the strategy pattern when you swap repositories. But if you're using a specific DB already remember YAGNI.
Regarding CQRS: Fowler's quote by pdr above still holds true here: "having the same conceptual model for commands and queries leads to a more complex model that does neither well" ... and you may need to use CQRS or similar. But it is much more expensive from a development and maintainence standpoint. If you are a packages vendor in competition with others, it might pay. If you're writing a custom LOB app for one customer, shooting for perfection is a poor choice. You need to decide if the value in having a completely or mostly double model is worth the extra effort. Specification is a good compromise because it allows you to make this separation in just one little part of the program that needs it, with the (development) speed and simplicity of one model. Good luck!