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.
7
In your particular case, as a rule of thumb, methods which operate on a single entity should be defined on the model itself, whilst those methods which operate on the entity collection as a whole should be defined on the service.
Methods such as getLatest
, getMostPopular
, getOutOfStock
, deleteFromPublisher
, deleteFromAuthor
are all ideal candidates for being defined on the service in your architecture, since such queries would inspect all existing entities.
To contrast, methods such as delete
, hide
, setStock
, setPrice
should ideally be defined on the model itself, since you would utilize these on a particular entity which you have in the current context.
Your concern that you might end up with a lot of such methods on the service is subjective. From the perspective of maintenance, there are ways to deal with this should it become unbearable, but it still doesn’t change the fact that these should be qualified from the service object itself.
7