应用程序服务对象，它们是否应该包含调用域服务方法的方法答案

【问题标题】：Application Service Objects, should they contain methods which call domain service methods应用程序服务对象，它们是否应该包含调用域服务方法的方法
【发布时间】：2013-07-10 01:43:08
【问题描述】：

我正在寻找答案，但找不到任何答案。

我们有一个包含服务和 POCO 的域层。然后我们有一个 ApplicationService 层，其中包含委托域层服务并将 POCO 映射到上层对象的服务。

上层对象得到扩展。例如我们有产品。我现在添加了一个方法，让它调用“getPrice”，它调用价格服务的“getPrice”方法，并传递自己的productID作为参数来检索该产品的价格。价格服务是通过将构造函数注入到产品中来引入的。

现在我问自己这是否是一个糟糕的设计。我们只是扩展应用服务中的对象，域中的对象还是POCO。

这个概念的缺点在哪里？

【问题讨论】：

您是在要求强化您的想法，还是您有想要避免的特定技术问题？是什么告诉你这是糟糕的设计？
有人指出但无法指出缺陷。对我来说，这简化了我的代码，我看不出它的哪一部分是危险的或错误的，我正在寻找这一部分。如果这不是糟糕的设计，我可以接受。

标签： c# asp.net dependency-injection domain-driven-design poco

【解决方案1】：

有关应用程序服务、域服务和域实体之间关系的示例，请查看here。

简而言之，应用程序服务封装您的域并通过协调存储库和其他服务将行为委托给域对象。这似乎与你所描述的一致。

您似乎偏离了方向的地方是将服务注入产品实体。在 DDD 中通常不鼓励这样做。相反，如果实体上的特定行为需要服务，则将服务传递给实现该行为的方法。将服务注入实体的一些缺点是：

您的实体变得更难以推理。
它必须成为依赖注入图的一部分，使其使用更加复杂。
它违反了 SRP，因为可能只有一种行为需要该服务。

【讨论】：

【解决方案2】：

您正在描述领域驱动设计。 DDD 最重要的问题是它很容易陷入“贫血”设计——这意味着您拥有自己的域、服务、聚合根、存储库等。但它们只会增加不必要的复杂性，而不是真正简化开发.

一个具体的问题 - 您的 Product 实体与应用程序相关联，还是 Product 真的是域实体？ productID 在应用范围内是否有意义？您提及 ID 会引发黄旗。

分别：

就风格而言，我喜欢将代理键（如 productID）保留在应用程序层之外，它除了在域中来回传递之外没有其他用途。进入应用层后，我更喜欢依赖自然键。

【讨论】：

前端是一个 MVC 项目，需要产品 id 作为 url。产品是一个领域对象，我们使用 automapper 将其映射到应用服务。在应用程序服务中，我在对象上添加了 getPrice 等方法，以便您可以通过调用此方法而不是调用其他服务来获取价格。您也不必知道产品的 id，因为它已经知道了。
听起来没问题，只要您的应用服务只与域服务对话而不与域产品实体对话。
再想一想——你仍然可以使用“产品编号”或“产品代码”来识别应用层和MVC领域的产品。