这是来自埃里克·埃文斯Domain Driven Design的书，还是来自别的地方？
哪里有一些很好的解释背后的推理？
编辑：澄清：我不是在谈论分离数据访问扎进从业务逻辑的分层的经典OO实践 – 我说的是具体的安排，在DDD，实体不应该去跟数据访问层(即它们不应该保存对Repository对象的引用)
更新：我给了奖励BacceSR，因为他的答案似乎最近，但我仍然在黑暗中这个很漂亮。如果这样一个重要的原则，应该有一些好的文章在网上在某处，肯定？
更新：2013年3月，关于这个问题的upvote意味着对这个很感兴趣，即使有很多答案，我仍然认为如果人们有这个想法有更多的空间。
这样，您就可以非常清楚地分离业务逻辑和更新事务。你没有一个孩子是谁自己，写这个程序，所有这些复杂的东西到产品目录，当它把它整合到上游项目，你坐在那里看着它，并实现它所有都必须开沟。这也意味着当人们加入团队，添加新功能，他们知道去哪里和如何构建程序。
可是等等！ Repository还引用持久层，如在Repository Pattern中。在一个更好的世界中，一个埃里克·埃文斯的仓库和存储库模式将有不同的名称，因为它们往往重叠了很多。要获取存储库模式，您需要使用服务总线或事件模型系统与其他访问数据的方式进行对比。通常当你达到这个级别，埃里克·埃文斯的存储库定义顺着一边，你开始谈论有界的上下文。每个有界的上下文本质上是它自己的应用程序。您可能有一个复杂的审批系统将事物放入产品目录。在您的原始设计中，产品是中心件，但在有限的上下文中，产品目录是。您仍然可以通过服务总线访问产品信息和更新产品，但是您必须意识到有限上下文之外的产品目录可能意味着完全不同。
回到你原来的问题。如果你从一个实体访问一个存储库，这意味着实体实际上不是一个业务实体，但可能是应该存在于服务层中的东西。这是因为实体是业务对象，并应该关心自己尽可能像DSL(领域特定语言)。在此图层中只有业务信息。如果您要排查效能问题，就必须在其他地方查看，因为只有商家资讯才会显示在这里。如果突然，你在这里有应用程序的问题，你很难扩展和维护一个应用程序，这是真正的DDD的核心：制作可维护的软件。
对意见的回应1：对，好问题。所以不是所有的验证发生在域层。夏普有一个属性“DomainSignature”，做你想要的。它是持久性感知，但作为一个属性保持域层清洁。它确保您没有重复实体，在您的示例中具有相同的名称。
但是让我们来谈谈更复杂的验证规则。假设您是Amazon.com。你有没有订购过期信用卡的东西？我有，我没有更新的卡，买了一些东西。它接受命令，UI通知我一切都是桃子。大约15分钟后，我会收到一封电子邮件，说明我的订单有问题，我的信用卡无效。这里发生的是，理想情况下，在域层中有一些正则表达式验证。这是一个正确的信用卡号码？如果是，请保留订单。但是，在应用程序任务层还有其他验证，其中会查询外部服务，以查看是否可以在信用卡上进行付款。如果没有，不要实际运送任何东西，暂停订单，等待客户。这应该都发生在服务层。
不要害怕在可以访问存储库的服务层创建验证对象。只是把它从域层。
