我的域对象可以了解存储库和 ServiceLayer 吗？

Question

我正在设计一个 C# 分层应用程序，我想知道我的域对象是否可以了解存储库和 ServiceLayer。

如果不是 - 我该如何解决 Article.CalculatePrice() 或 Offer.CalculatePrice 等复杂函数，恕我直言，它们应该遍历所有项目并汇总 Item.GetPrice()。

顺便说一句，我正在使用 EF5。

更新： 我的场景如下：我必须在不遵循任何可以想象的规则和某种奇怪的价格计算场景的遗留数据库之上构建它：

例如我有一个Article A { Type: Curtain, Color: Blue, Dimension: 200cm }，但没有在数据库中定义特定价格的文章 -> 所以我必须查看所谓的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，它必须返回根据组计算的价格。因此，如果我将整个内容封装在一个域对象中，我的 ArticleDO 就必须知道 ArticlePriceService，而后者必须知道 PriceGroupService？

我真的很困惑如何解决这个问题。请尝试提供一个例子或我..

Answer 1

恕我直言，它应该遍历所有项目并汇总 Item.GetPrice()。

如果您需要一个存储库来单独获取Items，那么听起来您可能没有明确定义的聚合。理想情况下，Article 和 Offer 聚合应该已经拥有这些信息，并且能够在没有任何外部数据的情况下进行计算。

如果需要一些外部数据（例如增值税率），那么这种行为应该封装在Domain Service 中。在这种情况下，可能是ArticlePriceCalculator 和OfferPriceCalculator 服务。

更新 似乎您的旧数据库正在渗入您的域。这是需要避免的事情。就普遍存在的语言而言，保持领域“纯粹”，不要让数据库的性质影响您的领域模型设计。一旦您有了一个精心设计的表达业务关注点（而不是数据库关注点）的域模型，您就可以考虑从数据库中获取数据并进入模型的最佳方式。鉴于您有一个旧数据库，我强烈建议您使用anti-corruption layer。该层旨在为您的美丽域和丑陋的数据库之间提供一道屏障。数据库架构中的任何怪癖和怪癖都应在此处处理，以免影响您的域模型的设计。