我知道域逻辑应该放在域对象中。但是，如果我的域逻辑需要数据库中的数据怎么办？（例如检查唯一值、计算值等）我认为将存储库注入我的域对象不是正确的事情。此外，服务层不应包含业务规则。那么如何解决这种业务逻辑呢？
你是对的，你的域对象不应该直接从数据库中读取数据。此处的经典错误是，域对象通过 Web 服务发送，并尝试从数据库中读取数据，而该对象位于无法访问数据库的服务器上。
有几种方法可以做到这一点：
- 服务层预加载域对象所需的任何信息
- 域对象可以调用从数据库获取数据的帮助程序或存储库
我一直发现服务层是调用此类活动的逻辑位置 - 但正如我将解释的那样，这不是我实现它本身的地方。 由于服务层是您进入域的网关，因此您可以放心，无论哪个请求正在启动对此数据的需求，它都必须通过此点才能到达那里。
此外，让服务与其他服务通信非常干净，因为它们专门设计为需要最少的调用工作。 您可以在存储库中公开所需的足够功能（即可以为您提供与 Y 条件匹配的 X 对象计数的方法/查找器/查询），并将其包装在方便的服务调用中。 这不仅使您能够在单个服务中轻松完成任务，还可以在服务之间利用此功能来满足更复杂的要求。
我理解将业务逻辑放在服务层的担忧，但根据要求，业务逻辑和特定于实现的业务逻辑之间是一条细线。 在编写系统时，经常会出现一些规则，这些规则被隐含为业务逻辑，但就是不适合。 独特的约束是我发现最常见的例子。 请记住，就像存储库中的其他所有内容一样，这不是服务层中的实现，而是域中已有内容的抽象。
我所做的是将"逻辑"本身放在域中，通常以规范模式实现的形式。 由于逻辑是在存储库中执行的，并且不需要更改服务层，因此我已经同意这是完全可以接受的。 您会发现适用于实体集合的规则通常是"有趣"的规则。 如果只需要验证聚合根中的集合是否具有唯一性，则操作非常简单。
我见过域对象了解存储库的方法，我个人不是粉丝。 对我来说，存储库是域如何与持久性层交互的定义（尽管并不总是实现）。 一个实体甚至知道它有一个比仅仅存在更伟大的目的，这一事实使事情变得非常复杂。