Is it okay for my Domain Objects to know about Repositories and ServiceLayer?

Question

I'm designing a C# layered application and I'd like to know if it is okay for my Domain Objects to know about the Repositories and the ServiceLayer.

If not - how do I solve complex functions like Article.CalculatePrice() or Offer.CalculatePrice, which should IMHO iterate through all items and summarice Item.GetPrice().

I"m using EF5 btw.

UPDATE: My scenario is as followed: I have to build this on top of a legacy DB that doesn't follow any imaginable rules and some kind of bizarre price calculation scenarios:

e.g. I have an Article A { Type: Curtain, Color: Blue, Dimension: 200cm }, but there is no article with a specific price defined in the DB -> so I have to look in so called PriceGroups which pricebuilding rules apply.

There may for example be the following groups that apply to the article:

 - Article A { Type: Curtain, Color: Blue, Dimension: 200cm } <-- does not exist
 - PriceGroup { Type: Curtain, Color: Blue, Dimension: NULL, Price: -5 EUR (*relative* price) }
 - PriceGroup { Type: Curtain, Color: NULL, Dimension 200cm, Price 25 EUR (*absolute* price) }

The thing is: PriceGroup and Article can not be aggregated in any way, and the price groups are not aligned hierachical, but they apply by specification.

So: IMHO the ArticlePriceService has to know about PriceGroups, hence if no ArticlePrice can be found, it has to return a Price calculated from the groups. So, if I box this whole thing in a Domain Object, my ArticleDO would have to know about the ArticlePriceService, which has to know about the PriceGroupService?

I'm really confused how to solve this problem. Please try to provide an example or me..

IMO no, you should solve these kind of problems in some kind of service — undefined, Jun 17 '13 at 08:45
Is "PriceGroup" a term that your domain expert would recognise? Or is it a technical fabrication? — MattDavey, Jun 17 '13 at 10:55
The term "PriceGroup" comes from the customer - who in the end - has to use the application on a daily basis.. — bberger, Jun 17 '13 at 11:36

MattDavey · Answer 1 · 2013-06-17T10:51:19.677

which should IMHO iterate through all items and summarice Item.GetPrice().

If you need a repository to go and fetch the Items separately, then it sounds like you might not have well defined aggregates. Ideally the Article and Offer aggregates should already have this information and be able to make the calculation without any external data.

If there is a requirement for some external data (perhaps VAT rate for example) then this kind of behaviour ought to be encapsulated in a Domain Service. In this case, perhaps ArticlePriceCalculator and OfferPriceCalculator services.

Update It seems as though your legacy database is bleeding into your domain. This is something that needs to be avoided. Keep the domain "pure" in terms of the ubiquitous language, do not allow the nature of the database to influence your domain model design at all. Once you have a carefully designed domain model which expresses the business concern (not the database concern), you can then think about the best way to get the data from the database and into the model. Given that you have a legacy database, I would strongly suggest an anti-corruption layer. This layer is designed to provide a barrier between your beautiful domain and the ugly database. Any quirks and eccentricities in the database schema should be dealt with here, so that it does not compromise the design of your domain model.

I updated my question to provide more insight of my problem. I'm not really sure how to design this scenario without having everything to know almost anything, that in my opinion shouldn't be the responsibility/concern of that specific domain.. — bberger, Jun 17 '13 at 10:36
Thank you for pointing me in the right direction. With this information I can definately move forward in my research — bberger, Jun 17 '13 at 12:18

Is it okay for my Domain Objects to know about Repositories and ServiceLayer?

1 Answers1