应用程序服务对象，如果它们包含调用域服务方法的方法
本文关键字：方法 服务 调用 包含 对象 如果 应用程序 | 更新日期: 2023-09-27 18:21:56
我正在寻找答案，但找不到任何答案。
我们有一个包含服务和POCO的域层。然后我们有一个ApplicationService层，它包含委托域层服务的服务，还将POCO映射到上层对象。
上层对象得到扩展。例如，我们有产品。我现在添加了一个方法，让它调用"getPrice"，它调用价格服务的"getPrice"方法，并将自己的productID作为参数来检索该产品的价格。价格服务是通过在产品中注入构造函数而引入的。
现在我在问自己这是不是一个糟糕的设计。我们只扩展了应用程序服务中的对象，域中的对象仍然是POCO。
这个概念的缺点在哪里？
有关应用程序服务、域服务和域实体之间关系的示例，请查看此处。
简而言之，应用程序服务封装您的域，并通过协调存储库和其他服务将行为委托给域对象。这似乎与你所描述的一致。
您似乎偏离了将服务注入产品实体的方向。DDD通常不鼓励这样做。相反，如果实体上的特定行为需要服务，请将服务传递给实现该行为的方法。将服务注入实体的一些缺点是：
- 你的实体变得更加难以推理
- 它必须成为依赖注入图的一部分，从而使其使用更加复杂
- 它违反了SRP，因为可能只有一种行为需要该服务
您正在描述领域驱动设计。DDD最主要的问题是，它很容易陷入"贫血"设计——这意味着你已经拥有了域、服务、聚合根、存储库等。但它们只会增加不必要的复杂性，而不是真正简化开发。
一个具体的问题-您的产品实体是否与应用程序关联，或者产品是否真的是域实体？productID在应用范围内有意义吗？你提到身份证就发出了危险信号。
另外：
作为一种风格，我喜欢将代理密钥（如productID）排除在应用程序层之外，因为它除了来回传递到域之外没有任何用途。进入应用程序层后，我更喜欢使用自然键。