0

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

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

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

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

这个概念的缺点在哪里？

4

2 回答 2

2

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

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

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

  1. 你的实体变得更难以推理。
  2. 它必须成为依赖注入图的一部分，这进一步复杂化了它的使用。
  3. 它违反了 SRP，因为可能只有一种行为需要该服务。
于 2013-07-11T18:27:53.853 回答
1

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

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

分别地：

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

于 2013-07-11T17:38:12.180 回答