Let's say we have Book
entity in our library. A requirement says:
Librarian may disable 'available' flag to books published before some year. For example, librarian may 'hide' some old books from being publicly available as they are rare.
This behavior is easily done with single SQL command. The method name for this behavior may be e.g. hideBooksPriorToYear()
.
But where to put this method?
if we put it in the Repository, soon it will be full of such methods; moreover, this is a business method, not a repo method.
we might fetch all old books and hide one by one, but this is slow.
we might create a business service for that, but that looks like anemic model again
we might put this method in a model, but I don't want to put sql there.
Any wisdom on this?
EDIT
Trying to clarify. When I try to move behavior to the entities methods, I found out that most of the business is not available without a repo. And I do not want to inject repo instance into the models. So my entities soon starts to be: 1) simple data objects, and 2) factories for entities/aggregates that are related to the model.
Book
, since it does not apply to a specific book in this case. But it sounds like the architecture could use some work first: ideally, SQL is separated from your domain models since it is implementation-specific. You should be able to swap out one SQL database for another or for NoSQL or a flat file without affecting your data models.