在哪里放置需要从数据库中获取数据的域逻辑

Question

我知道域逻辑应放在域对象中。但是如果我的域逻辑需要来自数据库的数据呢？ （例如，检查唯一值，计算值等等）我认为将存储库注入我的域对象是不对的。服务层也不应包含业务规则。那么如何解决这种业务逻辑？

Answer 1

您是对的，您的域对象不应直接从数据库中读取数据。这里的经典错误是域对象通过Web服务发送，并尝试从数据库中读取数据，当它位于服务器上而无法访问数据库时。

有几种方法可以做到这一点：

• 服务层预加载域对象需要的任何信息
• 域对象可以调用从数据库获取数据的帮助器或存储库

Answer 2

我总是发现服务层是调用此类活动的逻辑位置 - 但正如我将解释的那样，这不是我实现它的地方本身。由于服务层是您进入域的网关，因此您可以放心，无论什么请求启动了对此数据的需求，它都必须通过这一点才能到达那里。

此外，让服务与其他服务交谈是非常干净的，因为它们专门设计为需要最少的调用工作。您可以在存储库中公开所需的足够功能（即可以为您提供符合Y条件的X对象计数的方法/查找器/查询），并将其包装在方便的服务调用中。这不仅可以让您在单一服务中轻松完成任务，还可以在服务之间利用此功能来满足更复杂的需求。

我理解将业务逻辑放在服务层中的问题，但是根据需求，它是业务逻辑和什么是特定于实现的业务逻辑之间的界限。在编写系统时，通常会有一些表面暗示为业务逻辑而不适合的规则。我发现唯一的约束是最常见的例子。请记住，就像存储库中的其他所有内容一样，这不是服务层中的实现，而是对域中已有内容的抽象。

我所做的是将“逻辑”本身放在域中，通常以规范模式实现的形式。由于逻辑是在存储库中执行的，并且不需要更改服务层，因此我已经接受了这个完全可以接受的条款。您会发现适用于实体集合的规则通常是“有趣”的规则。如果您只需要在聚合根目录中验证某个集合的某些内容是唯一的，那么这很简单。

我已经看到了域对象知道存储库的方法，我个人不是粉丝。对我来说，存储库是域与持久层接口的定义（尽管并不总是实现）。一个实体甚至知道它有更大的目的而不仅仅是存在的事实使事情变得非常复杂。