I am refactoring an e-commerce web-application, currently working on the
UserBasket class, which will have to handle adding or removing items, changing their quantity, getting total amount, total number of items etc.. When displaying the basket, the item's name, description and main-image-filename are also needed.
UserBasketthen has to know the price of the
Item for the given quantity. Different methods of calculating the current applicable price should be swappable. I could employ the
Strategy pattern either in some sort of
ItemPriceGetter with which the
UserBasket would be constructed, leaving the item unaware of this, or construct the
Item itself with a
I have reservations against a completely anemic domain model. An item should be able to tell me its price for a certain customer and quantity on a certain date - it should be able to tell the filename of its main image, its availability etc.
Essentially, in the database, items (and other domain entities) have multiple 1-to-n relations with sometimes complex and varying logic to find the currently applicable one among them (for price, image, description etc).
If I don't want an anemic domain model, but there will be different strategies for getting the 'right' related information, how do I avoid constructor over-injection when there are multiple such 1-to-n relations from an item where a strategy to chose the right one is needed.
Item-Class is there to tell you about data relating to items, and perform business logic that is centered around them - so making it able to tell you its price for a given customer and quantity, its main-image-filename or some such doesn't seem like a violation of the Single Responsibility Principle.
With an anemic domain model, I would have the logic neatly divided and encapsulated, but now, for - say - an itemlist to find out availability, price, name and image of an item, it would need not just an item, but also an
ItemImageFinder (or some such) - cohesion would (seemingly) suffer, and things that properly belong to the item are no longer encapsulated there.
With a rich domain model, the item itself will have to have an
ItemImageStrategy or similar. So it seems I'm stuck with either injecting a lot of dependencies or losing coherence and making my domain model anemic... and in the latter case, I would still have classes (which e.g. need a lot of info about Items) which I would have to construct with the Domain Object itself and most of the services to get related data.
What is the best practice to deal with such a situation? Specifically: How should the different ways of getting and filtering the related information for one kind of business entity based on contextual parameters be encapsulated and how should it be integrated so as to maximize coherence and avoid violating the single responsibility principle?