哪里需要从数据库中获取数据的域逻辑
我知道域逻辑应该放入域对象中。 但是，如果我的域逻辑需要来自数据库的数据呢？ （例如检查唯一值，计算值等）我认为向我的域对象注入存储库不是正确的事情。 此外，服务层不应包含业务规则。 那么如何解决这种业务逻辑呢？
你是对的，你的域对象不应该直接从数据库中读取数据。 这里的经典错误是域对象通过Web服务发送，并尝试从数据库读取数据，当数据库位于服务器上而不访问数据库时。
做这件事有很多种方法：
我一直认为服务层是调用这种活动的合理位置 - 但正如我将解释的那样，这不是我实施它的地方。 由于服务层是您进入域的入口，因此您可以确信，无论请求何时启动对此数据的需求，它都必须通过这一点才能实现。
另外，让服务与其他服务交谈是非常干净的，因为它们专门设计为只需要很少的努力即可调用。 您可以在存储库中公开需要的足够的功能（例如，可以为您提供匹配Y条件的X对象数的方法/查找程序/查询），并将其包装在方便的服务调用中。 这不仅可以让您在单一服务中轻松完成任务，还可以在服务之间利用此功能来实现更复杂的需求。
我理解将业务逻辑放入服务层的担忧，但根据需求，这是业务逻辑与特定于实现的业务逻辑之间的一条细线。 在编写一个系统时，经常会出现一些表面上隐含的业务逻辑但不适合的规则。 独特的约束是我发现的最常见的例子。 请记住，就像存储库中的所有其他内容一样，这不是服务层中的实现，而是对域中已有内容的抽象。
我所做的是将“逻辑”本身置于域中，通常以规范模式实现的形式。 由于逻辑是在存储库中执行的，并且不需要更改服务层，所以我接受了这个完全可以接受的条款。 你会发现适用于实体集合的规则通常是“有趣”的规则。 如果您只需要验证聚集根中的某个集合是否具有唯一性，那么这很简单。
我已经看到了域对象知道存储库的方法，而我个人不是粉丝。 对我来说，存储库是定义域如何与持久层接口（尽管不一定是实现）。 事实上，一个实体甚至知道它有一个更大的目的而不仅仅是存在，使事情变得非常复杂。
链接地址: http://www.djcxy.com/p/52767.html上一篇: Where to put domain logic which needs to fetch data from database