Domain-Driven Design - features of repositories?

Question

OOP

Good day to all!
DDD teaches us that if our application needs to load model objects, we need to use the appropriate repository. It is this class of objects that is responsible for storing the entities of our model.
In this regard, I have been tormented by an ideological question for a long time, I want to consult the habra community on this topic: what functions, besides the banal FindAll and FindById (well, Create / Save / Delete) should be included in the repository? If our application operates with entities of the User or Employee type, functions for downloading all active users, or users who have not appeared on the site for more than six months, will certainly be needed. Or, let's say, a method for obtaining the quantityusers who have not yet activated their account. What class should be responsible for this? On the one hand, it is logical to place such methods in the appropriate repositories, but on the other hand, we don’t need the entities themselves, we need some kind of projection.
What are your thoughts on this?

Answer 1

I re-read the chapter on repositories in Evans' book. He writes that the repository may contain methods for finding objects by their attribute values. In more general cases, the repository can include methods that accept specifications as input. And also - what interested me most of all, Evans explicitly confirms that methods can be included in the repository interface that return the result of simple operations on objects (by a given criterion). Great, issue resolved!

Answer 2

Uh-huh, there is another funny moment. The interface is collection-like, so the save (or update) method is optional. As a rule, I don't. I have something like put, get, getAll(), getAllBySpecification(). The delete method is also often missing, somehow logical deletion with a flag is usually more convenient.