在理想的情况下，DDD建议实体不应该引用数据层。但是我们并不是生活在理想的世界里。域可能需要引用与它们没有依赖关系的其他业务逻辑域对象。实体以只读的目的引用存储库层来获取值是合乎逻辑的。

这是出自Eric Evans的《领域驱动设计》一书，还是来自其他地方?

都是老东西了。埃里克的书让它更热闹了。

对其背后的原因有什么好的解释吗?

原因很简单——当人类面对模糊相关的多种情境时，大脑会变得脆弱。它们导致了歧义(美国在南/北美意味着南/北美)，歧义导致了每当大脑“接触到”信息时，信息的不断映射，这总结起来就是糟糕的生产力和错误。

业务逻辑应该尽可能清晰地反映出来。外键、归一化、对象关系映射是完全不同的领域——那些东西是技术上的，与计算机有关。

打个比方:如果你正在学习如何写字，你就不应该被笔是在哪里制造的，为什么墨水能在纸上保持，纸是什么时候发明的，以及中国还有哪些其他著名的发明。

编辑:澄清一下:我不是在谈论将数据访问从业务逻辑分离到一个单独层的经典OO实践——我是在谈论DDD中的具体安排，即实体根本不应该与数据访问层对话(即它们不应该持有对Repository对象的引用)。

原因和我上面提到的一样。这里只是更进一步。如果实体可以(至少接近)完全忽略持久性，为什么它们应该部分忽略持久性?我们的模型所包含的与领域无关的问题更少——当我们不得不重新解释它时，我们的大脑获得了更多的喘息空间。

虽然来晚了，但我还是会说点我的意见。

从性能角度来看，在域模型中抽象REST API操作的存储库和域服务可能是一个重大灾难。我认为无论是域服务(尽管在红皮书中有其他说法!)，还是聚合都不应该尝试与它们合作，这两个概念应该只留在应用服务领域，无论你使用Layers还是Hexagon(端口和适配器)，它都有与外部世界通信的唯一责任。

通过这种方式，所有昂贵的I/O通信都由一个应用程序服务分配并完全控制。它将:

防止任何类型的性能瓶颈。 在域模型中防止任何类型的全局访问(存储库是全局的)。

建立正确的对象图，在应用服务中使用正确的抓取策略，将纯内存中的对象传递给富域模型。惰性加载会潜入你的代码，并在最痛的地方打击你。

To cite Carolina Lilientahl, "Patterns should prevent cycles" https://www.youtube.com/watch?v=eJjadzMRQAk, where she refers to cyclic dependencies between classes. In case of repositories inside aggregates, there is a temptation to create cyclic dependencies out of conveniance of object navigation as the only reason. The pattern mentioned above by prograhammer, that was recommended by Vernon Vaughn, where other aggregates are referenced by ids instead of root instances, (is there a name for this pattern?) suggests an alternative that might guide into other solutions.

类之间循环依赖的例子(忏悔):

(Time0): Sample和Well这两个类彼此引用(循环依赖)。Well指的是Sample，而Sample指的是Well，这是为了方便(有时是对样品进行循环，有时是对一个板中的所有孔进行循环)。我无法想象样本不会指向它所在的井。

(Time1):一年之后，许多用例实现了....现在有一些情况下，样本不应该指向它所在的井。在一个工作步骤内有临时板。这里的孔指的是样品，而样品又指的是另一个盘子上的孔。正因为如此，当有人试图实现新功能时，有时会出现奇怪的行为。渗透需要时间。

我也从上面提到的这篇关于惰性加载的负面方面的文章中得到了帮助。

为什么要分离数据访问?

从书中，我认为模型驱动设计一章的前两页给出了一些理由，说明为什么要从领域模型的实现中抽象出技术实现细节。

您希望在领域模型和代码之间保持紧密的连接 分离技术关注点有助于证明模型对于实现是可行的 你希望无处不在的语言渗透到系统的设计中

这似乎都是为了避免独立的“分析模型”与系统的实际实现分离。

根据我对这本书的理解，它说这个“分析模型”可以在不考虑软件实现的情况下被设计出来。一旦开发人员试图实现业务方面理解的模型，他们就会由于需要而形成自己的抽象，从而在交流和理解中造成障碍。

在另一个方向上，开发人员在领域模型中引入太多的技术关注也会导致这种分歧。

因此，您可以考虑实践关注点分离，例如持久性，可以帮助防止这些设计和分析模型出现分歧。如果觉得有必要在模型中引入持久性之类的东西，那么这就是一个危险信号。也许这个模型对于实现来说并不实用。

引用:

“单一模型减少了出错的可能性，因为现在的设计是经过仔细考虑的模型的直接产物。设计，甚至代码本身，都具有模型的交流性。”

我对此的解释是，如果你最终要用更多行代码来处理数据库访问之类的事情，你就失去了交流能力。

如果需要访问数据库是为了检查唯一性之类的事情，请查看:

Udi Dahan:团队在应用DDD时所犯的最大错误

http://gojko.net/2010/06/11/udi-dahan-the-biggest-mistakes-teams-make-when-applying-ddd/

"所有规则都是不平等的"

and

使用领域模型模式

http://msdn.microsoft.com/en-us/magazine/ee236415.aspx#id0400119

在“不使用领域模型的场景”中，涉及到相同的主题。

如何分离数据访问

通过接口加载数据

“数据访问层”已经通过一个接口抽象出来，你可以调用它来检索所需的数据:

var orderLines = OrderRepository.GetOrderLines(orderId);

foreach (var line in orderLines)
{
     total += line.Price;
}

优点:该接口分离了“数据访问”管道代码，允许您仍然编写测试。数据访问可以在逐案处理的基础上，允许比通用策略更好的性能。

缺点:调用代码必须假定哪些已加载，哪些未加载。

出于性能原因，GetOrderLines返回带有空ProductInfo属性的OrderLine对象。开发人员必须非常了解接口背后的代码。

我在实际系统中尝试过这种方法。为了修复性能问题，您不得不一直更改加载内容的范围。最后，您需要查看接口背后的数据访问代码，以查看加载了什么，没有加载什么。

现在，关注点分离应该允许开发人员一次尽可能多地关注代码的一个方面。接口技术删除了数据是如何加载的，但没有删除加载了多少数据、何时加载以及在何处加载。

结论:分离度相当低!

延迟加载

数据按需加载。加载数据的调用隐藏在对象图本身中，其中访问属性可能导致在返回结果之前执行sql查询。

foreach (var line in order.OrderLines)
{
    total += line.Price;
}

优点:数据访问的“时间、地点和方式”对于专注于领域逻辑的开发人员来说是隐藏的。在聚合中没有处理加载数据的代码。加载的数据量可以是代码所需的确切数量。

缺点:当你遇到性能问题时，如果你有一个通用的“一刀切”的解决方案，就很难解决问题。延迟加载会导致整体性能变差，实现延迟加载可能很棘手。

角色接口/主动抓取

每个用例都是通过聚合类实现的角色接口显式实现的，允许每个用例处理数据加载策略。

抓取策略可能是这样的:

public class BillOrderFetchingStrategy : ILoadDataFor<IBillOrder, Order>
{
    Order Load(string aggregateId)
    {
        var order = new Order();

        order.Data = GetOrderLinesWithPrice(aggregateId);
    
        return order;
    }

}
   

然后你的集合看起来像这样:

public class Order : IBillOrder
{
    void BillOrder(BillOrderCommand command)
    {
        foreach (var line in this.Data.OrderLines)
        {
            total += line.Price;
        }

        etc...
    }
}

BillOrderFetchingStrategy用于构建聚合，然后聚合完成它的工作。

优点:允许为每个用例定制代码，从而实现最佳性能。符合界面隔离原则。没有复杂的代码需求。聚合单元测试不必模拟加载策略。一般的加载策略可以用于大多数情况下(例如“加载全部”策略)，特殊的加载策略可以在必要时实现。

缺点:开发者在修改域代码后仍然需要调整/审查抓取策略。

使用获取策略方法，您可能仍然会发现自己在更改业务规则时更改自定义获取代码。这不是一个完美的关注点分离，但最终会更易于维护，并且比第一种选择更好。抓取策略确实封装了如何、何时和何处加载数据。它具有更好的关注点分离，而不会像“一刀切”的惰性加载方法那样失去灵活性。

实体只捕获与其有效状态相关的规则。其中的数据有效吗?其中的数据可以这样改变吗?

聚合根对一组实体执行相同的操作。汇总的数据有效吗?总体数据能以这种方式改变吗?

域服务捕获关于实体或聚合之间更改的规则。我们可以这样改变X和Y吗?

None of this ever requires access to a repository or to infrastructure. What you do is that an application service will offer up a domain use case, for that use case, the application service will gather all the needed data from the repositories, that will return it your domain entities and/or aggregate roots and their value objects. The entities/aggregate roots and value objects would have validated that they are in a good state when created by the repository. Then the application service will use a combination of those entities (some of them could be aggregate roots), to perform the domain use case. If the domain use case requires changing X, Y and Z, the application service will ask X, Y and Z entities/aggregate roots if the current use case request of changes can be made to X, Y and Z, and if so, how should it be made. Finally, the application service will commit those changes back to the repository.

如果某些更改跨越实体或聚合，应用程序服务将使用域服务询问是否可以进行更改以及如何进行更改，并再次使用存储库提交这些更改。

如果一个域用例跨越多个有界上下文，这意味着它需要跨有界上下文的信息或更改，这被称为流程，并且您可以让一个流程服务管理整个流程生命周期，它将利用多个有界上下文的应用程序服务来跨所有有界上下文协调整个流程。

Finally, the application service can also use other application services, could be other micro-services in a shared bounded context, that would imply they share the same domain model, or it could do so across to application services in other bounded contexts, in which case you'd want to model those within your own bounded context's domain model as well, you'd treat those other bounded contexts much like a repository in a way. The application service communicates with another bounded context to get info about that other context, it then creates a representation of that info within its own domain model, using its own entities and VOs, and aggregates, which will again validate that state within their context. Similarly, you can commit changes to your domain model to other bounded contexts by asking them to change accordingly. All this can be implemented with direct method calls, remote API calls, async events, shared kernel, etc.

And to answer why it is like so, that's because the whole point is building software that can evolve over time without it becoming slower to make changes to it and add/modify its behavior while retaining its current correctness with regards to its current functionality. A good way to do this is by making it a change in one place doesn't break things elsewhere. This is why bounded contexts exist, already changes are restricted to each context, so a change in one is less likely to break another. This is also why the domain model validates all changes to the domain state, so you can't change part of the state in ways that breaks other usage of it. This is why aggregates are used, to maintain a change boundary between the things that need one, and clearly not have one where it doesn't need one. Finally, by having the whole domain layer, with domain model and domain services, not depend on any infrastructure, like the repository (and thus the DB), a change to the DB or repository will also not be able to break your domain model or services.

P.S.: Also note I use the term "state" loosely. It doesn't have to be a static value; state could be the application of some dynamic computation or rules that generates state when requested. You can have something like totalItemsCount on some entity which computes it when asked about what is the current totalItemsCount for the entity. Again, the entity will make sure to return you valid state, that means it will know how to correctly count the total and make sure that what is returned is the correct application of the domain rules for totalItemsCount.