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

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

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

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

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

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

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

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

为什么要分离数据访问?

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

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

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

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

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

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

引用:

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

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

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

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用于构建聚合，然后聚合完成它的工作。

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

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

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

这是一个非常好的问题。我期待着就此进行一些讨论。但我想DDD的几本书里都提到了吉米·尼尔森斯和埃里克·埃文斯。我想通过示例也可以看到如何使用存储库模式。

BUT lets discuss. I think a very valid thought is why should an entity know about how to persist another entity? Important with DDD is that each entity has a responsibility to manage its own "knowledge-sphere" and shouldn't know anything about how to read or write other entities. Sure you can probably just add a repository interface to Entity A for reading Entities B. But the risk is that you expose knowledge for how to persist B. Will entity A also do validation on B before persisting B into db?

正如您所看到的，实体A可以更多地参与到实体B的生命周期中，这可以为模型增加更多的复杂性。

我猜(没有任何例子)单元测试将会更加复杂。

但是我确信总会有这样的场景:您想通过实体来使用存储库。你必须考虑每一种情况才能做出有效的判断。优点和缺点。但是在我看来，存储库实体解决方案有很多缺点。它一定是一个非常特殊的场景，优点抵消了缺点....

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

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

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

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

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

对我来说，这似乎是与OOD相关的一般良好实践，而不是DDD特有的。

我能想到的原因是:

关注点分离(实体应该与它们的持久化方式分离。因为根据使用场景的不同，可能存在多种策略，其中相同的实体将被持久化) 从逻辑上讲，实体可以在存储库操作的级别之下的级别中看到。较低级别的组件不应该具有较高级别组件的知识。因此，条目不应该有关于存储库的知识。

在所有这些单独的层出现之前，我学会了编写面向对象的编程，我的第一个对象/类确实直接映射到数据库。

最后，我添加了一个中间层，因为我必须迁移到另一个数据库服务器。同样的场景我已经看过/听说过好几次了。

我认为分离数据访问(又名。“存储库”)来自您的业务逻辑，是那些已经被重新发明了几次的东西之一，尽管领域驱动设计书，使它有很多“噪音”。

我目前使用3层(GUI，逻辑，数据访问)，像许多开发人员一样，因为这是一个很好的技术。

将数据分离到存储库层(又名数据访问层)，可以看作是一种良好的编程技术，而不仅仅是一种规则。

像许多方法一样，一旦您理解了它们，您可能希望从NOT implemented开始，并最终更新您的程序。

引用: 《伊利亚特》不完全是荷马发明的，《卡米娜·布兰娜》也不完全是卡尔·奥尔夫发明的，在这两种情况下，把别人的工作放在一起的人得到了荣誉;-)