应用程序服务对象,如果它们包含调用域服务方法的方法

本文关键字:方法 服务 调用 包含 对象 如果 应用程序 | 更新日期: 2023-09-27 18:21:56

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

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

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

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

这个概念的缺点在哪里?

应用程序服务对象,如果它们包含调用域服务方法的方法

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

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

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

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

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

一个具体的问题-您的产品实体是否与应用程序关联,或者产品是否真的是域实体?productID在应用范围内有意义吗?你提到身份证就发出了危险信号。

另外:

作为一种风格,我喜欢将代理密钥(如productID)排除在应用程序层之外,因为它除了来回传递到域之外没有任何用途。进入应用程序层后,我更喜欢使用自然键。