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

Question

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

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

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

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

这个概念的缺点在哪里？

Answer 1

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

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

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

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

Answer 2

您正在描述域驱动设计。 DDD最重要的问题是它很容易陷入贫血症状。设计 - 意味着您已经获得了域，服务，聚合根，存储库等。但它们只会增加不必要的复杂性，而不是真正简化开发。

具体问题 - 您的产品实体是否与应用程序相关联，或者产品是否真的是域实体？ productID是否具有应用范围的含义？你提到身份证会引起一面黄旗。

单独：

作为一种风格问题，我喜欢将代理键（例如productID）保留在应用程序层之外，除了来回传递到域之外没有任何意义。一旦到达应用层，我更喜欢依赖自然键。