我正在设计一个C＃分层应用程序，我想知道我的Domain Objects是否可以了解存储库和ServiceLayer。
如果没有 - 我如何解决像Article.CalculatePrice（）或Offer.CalculatePrice这样的复杂函数，这应该恕我直言遍历所有项目和summarice Item.GetPrice（）。
我正在使用EF5 btw。
更新 我的方案如下：我必须在遗留数据库的基础上构建它，不遵循任何可以想象的规则和某种奇怪的价格计算方案：
e.g。我有Article A { Type: Curtain, Color: Blue, Dimension: 200cm }，但没有在数据库中定义特定价格的文章 - ＆gt;所以我必须查看所谓的PriceGroups适用的价格构建规则。
例如，可能有以下适用于该文章的组：
- 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) }
事情是：PriceGroup和Article不能以任何方式汇总，价格组不是按层次排列，而是按规范应用。
所以：恕我直言，ArticlePriceService必须了解PriceGroups，因此如果找不到ArticlePrice，它必须返回从这些组计算的价格。所以，如果我在Domain Object中将整个内容打包，我的ArticleDO必须知道ArticlePriceService，它必须知道PriceGroupService吗？
我真的很困惑如何解决这个问题。请尝试提供一个例子或我..
答案 0 :(得分：1)
应该恕我直言所有项目和总结Item.GetPrice（）。
如果您需要一个存储库来单独获取Items，那么听起来您可能没有明确定义的聚合。理想情况下，Article和Offer聚合应该已经拥有此信息，并且无需任何外部数据即可进行计算。
如果需要某些外部数据（例如增值税率），那么这种行为应该封装在Domain Service中。在这种情况下，可能是ArticlePriceCalculator和OfferPriceCalculator服务。
<强>更新 您的遗留数据库似乎正在渗透到您的域中。这是需要避免的。根据无处不在的语言保持域“纯粹”，不要让数据库的性质影响您的域模型设计。一旦您有一个精心设计的域模型来表达业务问题（而不是数据库问题），您就可以考虑从数据库和模型中获取数据的最佳方法。鉴于您有遗留数据库，我强烈建议使用anti-corruption layer。此图层旨在为您的美丽域和丑陋的数据库之间提供屏障。应该在这里处理数据库模式中的任何怪癖和怪癖，这样它就不会影响域模型的设计。