DDD - 实体不能直接访问存储库的规则

Question

在领域驱动设计中，似乎有很多 < href="https://stackoverflow.com/questions/827670/is-it-ok-for-entities-to-access-repositories/827693#827693">协议实体不应直接访问存储库。

这是来自 Eric Evans 领域驱动设计

对于其背后的推理，哪里有一些好的解释？

编辑：澄清一下：我不是在谈论将数据访问与业务逻辑分离到单独层的经典 OO 实践 - 我是在谈论 DDD 中的具体安排，实体不应该与数据对话完全访问层（即它们不应该保存对存储库对象的引用）

更新：我给了 BacceSR 赏金，因为他的答案似乎最接近，但我对此仍然一无所知。如果这是一个如此重要的原则，那么网上应该有一些关于它的好文章，当然吗？

更新：2013 年 3 月，对该问题的投票表明人们对此很感兴趣，尽管已经有很多答案，但我仍然认为如果人们对此有想法，还有更多的空间。

Answer 1

这里有点混乱。存储库访问聚合根。聚合根是实体。这样做的原因是关注点分离和良好的分层。这对于小型项目来说没有意义，但如果您在一个大型团队中，您想说，“您通过产品存储库访问产品。产品是实体集合（包括 ProductCatalog 对象）的聚合根。如果您想更新 ProductCatalog，则必须通过 ProductRepository。”

通过这种方式，您可以非常非常清晰地分离业务逻辑和更新内容。你不会有一个孩子独自一人编写整个程序，对产品目录执行所有这些复杂的事情，当涉及到将其集成到上游项目时，你坐在那里看着它并意识到它一切都必须被抛弃。这也意味着当人们加入团队、添加新功能时，他们知道该去哪里以及如何构建程序。

但是等等！存储库也指持久层，如存储库模式中所示。在一个更好的世界中，Eric Evans 的存储库和存储库模式应该有不同的名称，因为它们往往有很多重叠。为了获得存储库模式，您需要与其他访问数据的方式（使用服务总线或事件模型系统）进行对比。通常，当您达到这个级别时，Eric Evans 的存储库定义就会被忽略，您会开始讨论有界上下文。每个有界上下文本质上都是它自己的应用程序。您可能有一个复杂的审批系统来将东西放入产品目录中。在最初的设计中，产品是中心部分，但在这个有限的上下文中，产品目录才是中心部分。您仍然可以通过服务总线访问产品信息并更新产品，但您必须意识到有界上下文之外的产品目录可能意味着完全不同的东西。

回到你原来的问题。如果您从实体内部访问存储库，则意味着该实体实际上不是业务实体，而可能应该存在于服务层中。这是因为实体是业务对象，并且应该关注尽可能类似于 DSL（领域特定语言）。这一层只有业务信息。如果您正在解决性能问题，您就会知道要寻找其他地方，因为这里应该只包含业务信息。如果突然出现应用程序问题，那么扩展和维护应用程序就会变得非常困难，而这正是 DDD 的核心：制作可维护的软件。

对评论 1 的回复：好的，好问题。因此，并非所有验证都发生在域层中。 Sharp 有一个属性“DomainSignature”可以满足您的需求。它具有持久性意识，但作为一个属性可以保持域层的干净。它确保您没有在示例中具有相同名称的重复实体。

但我们来谈谈更复杂的验证规则。假设您是 Amazon.com。您是否曾经使用过期的信用卡订购过商品？我有，但我还没有更新卡并购买东西。它接受订单，用户界面告诉我一切都很顺利。大约 15 分钟后，我会收到一封电子邮件，说我的订单有问题，我的信用卡无效。理想情况下，这里发生的情况是在域层中有一些正则表达式验证。这是正确的信用卡号码吗？如果是，则保留该顺序。但是，在应用程序任务层有额外的验证，其中查询外部服务以查看是否可以通过信用卡进行付款。如果没有，就不要实际发货，暂停订单并等待客户。这一切都应该发生在服务层中。

不要害怕在可以访问存储库的服务层创建验证对象。只要将其置于域层之外即可。

Answer 2

起初，我劝说允许我的一些实体访问存储库（即没有 ORM 的延迟加载）。后来我得出的结论是我不应该这样做，我可以找到替代方法：

1. 我们应该知道请求中的意图以及我们想要从域中得到什么，因此我们可以在构造或调用聚合行为之前进行存储库调用。这也有助于避免内存状态不一致的问题以及延迟加载的需要（请参阅此 文章）。味道是，您无法再在不担心数据访问的情况下创建实体的内存实例。
2. CQS 可以帮助减少调用存储库中的内容的需要我们的实体。
3. 我们可以使用规范来封装和传达领域逻辑需求将其传递给存储库（服务可以为我们协调这些事情）。该规范可以来自负责维护该不变量的实体。存储库会将规范的部分内容解释为它自己的查询实现，并将规范中的规则应用于查询结果。这样做的目的是将领域逻辑保留在领域层。它还可以更好地服务于通用语言和通信。想象一下说“逾期订单规范”与“从 tbl_order 过滤订单，其中placed_at 比系统日期早 30 分钟”（请参阅​​此 答案）。
4. 由于违反了单一责任原则，它使得对实体行为的推理变得更加困难。如果您需要解决存储/持久性问题，您知道该去哪里、不该去哪里。
5. 它避免了让实体双向访问全局状态（通过存储库和域服务）的危险。您也不想打破交易边界。

Vernon Vaughn 在红皮书 Implementing Domain-Driven Design 中据我所知在两个地方提到了这个问题（注：这本书得到了 Evans 的完全认可，你可以在前言中读到）。在有关服务的第 7 章中，他使用域服务和规范来解决聚合使用存储库和另一个聚合来确定用户是否经过身份验证的需求。引用他的话说：

根据经验，我们应该尽量避免使用存储库
(12) 如果可能的话，从聚合内部。

弗农，沃恩 (2013-02-06)。实施领域驱动设计（Kindle 位置 6089）。培生教育。 Kindle 版。

以及关于聚合的第 10 章中的 部分他在题为“模型导航” 的文章中说道（就在他建议使用全局唯一 ID 来引用其他聚合根之后）：

通过身份引用并不能完全阻止导航
模型。有些人会使用聚合内部的存储库 (12)
用于查找。这种技术称为断开域模型，并且
它实际上是延迟加载的一种形式。还有一个不一样的推荐
但是，方法是：使用存储库或域服务 (7) 进行查找
在调用聚合行为之前依赖对象。一位客户
应用程序服务可以控制这一点，然后分派到聚合：

他接着在代码中展示了一个示例：

public class ProductBacklogItemService ... { 
    ...
    @Transactional 
    public void assignTeamMemberToTask( 
        String aTenantId, 
        String aBacklogItemId, 
        String aTaskId, 
        String aTeamMemberId) { 

        BacklogItem backlogItem = backlogItemRepository.backlogItemOfId( 
            new TenantId(aTenantId), 
            new BacklogItemId(aBacklogItemId)); 

        Team ofTeam = teamRepository.teamOfId( 
            backlogItem.tenantId(), 
            backlogItem.teamId());

        backlogItem.assignTeamMemberToTask( 
            new TeamMemberId( aTeamMemberId), 
            ofTeam,
            new TaskId( aTaskId));
   } 
   ...
}

他接着还提到了如何在聚合命令方法中使用域服务以及 的另一种解决方案双重调度。 （我无法充分推荐阅读他的书有多么有益。当你厌倦了无休止地在互联网上翻阅之后，花当之无愧的钱来阅读这本书。）

然后我吃了一些与总是亲切的 Marco Pivetta @Ocramius 进行讨论 他向我展示了一些从域中提取规范并使用它的代码：

1. 不推荐这样做：

$user->mountFriends(); // <-- has a repository call inside that loads friends? 

2. 在域服务中，这很好：

public function mountYourFriends(MountFriendsCommand $mount) {
    $user = $this->users->get($mount->userId()); 
    $friends = $this->users->findBySpecification($user->getFriendsSpecification()); 
    array_map([$user, 'mount'], $friends); 
}

Answer 3

这是一个非常好的问题。我期待对此进行一些讨论。但我认为几本 DDD 书籍以及 Jimmy nilssons 和 Eric Evans。我想通过示例也可以看出如何使用存储库模式。

但我们来讨论一下。我认为一个非常有效的想法是为什么一个实体应该知道如何持久化另一个实体？ DDD 的重要之处在于，每个实体都有责任管理自己的“知识领域”，并且不应该知道如何读取或写入其他实体。当然，您可能只需向实体 A 添加一个存储库接口来读取实体 B。但风险在于您暴露了如何持久化 B 的知识。在将 B 持久化到数据库之前，实体 A 是否也会对 B 进行验证？

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

我想（没有任何例子）单元测试会更加复杂。

但我确信在某些情况下您总是想通过实体使用存储库。您必须查看每个场景才能做出有效的判断。优点和缺点。但在我看来，存储库实体解决方案有很多缺点。这一定是一个非常特殊的场景，优点平衡缺点......

Answer 4

多么好的问题啊。我走在同样的发现之路上，互联网上的大多数答案似乎带来的问题和解决方案一样多。

所以（冒着一年后我不同意写一些东西的风险）这是我迄今为止的发现。

首先，我们喜欢丰富的领域模型，它为我们提供了高可发现性（我们可以使用聚合做什么）和可读性（表达方法调用）。

// Entity
public class Invoice
{
    ...
    public void SetStatus(StatusCode statusCode, DateTime dateTime) { ... }
    public void CreateCreditNote(decimal amount) { ... }
    ...
}

我们希望在不向实体的构造函数中注入任何服务的情况下实现这一目标，因为：

• 引入新行为（使用新服务）可能会导致构造函数发生更改，这意味着更改会影响实例化实体的每一行！
• 这些服务不是模型的一部分，但构造函数注入表明它们是模型的一部分。
• 通常，服务（甚至其接口）是实现细节而不是域的一部分。域模型将具有面向外部的依赖项。
• 为什么没有这些依赖关系实体就无法存在，这可能会令人令人困惑。 （你说贷方票据服务？我什至不会对贷方票据做任何事情......）
• 这将使其难以实例化，因此难以测试。
• 该问题很容易蔓延，因为包含此实体的其他实体将获得相同的依赖关系 - 这对它们来说可能看起来非常不自然的依赖关系。

那么，我们怎样才能做到这一点呢？到目前为止我的结论是，方法依赖和双重调度提供了一个不错的解决方案。

public class Invoice
{
    ...

    // Simple method injection
    public void SetStatus(IInvoiceLogger logger, StatusCode statusCode, DateTime dateTime)
    { ... }

    // Double dispatch
    public void CreateCreditNote(ICreditNoteService creditNoteService, decimal amount)
    {
        creditNoteService.CreateCreditNote(this, amount);
    }

    ...
}

CreateCreditNote() 现在需要一个负责创建贷方票据的服务。它使用双重调度，将工作完全卸载给负责的服务，同时从Invoice实体保持可发现性。

SetStatus() 现在对记录器具有简单依赖，显然它将执行部分工作。

对于后者，为了使客户端代码更容易，我们可以通过 IInvoiceService 进行日志记录。毕竟，发票记录似乎是发票固有的。这样一个 IInvoiceService 有助于避免各种操作需要各种微型服务。缺点是该服务到底要做什么变得模糊。。它甚至可能开始看起来像双重调度，而大部分工作实际上仍然是在 SetStatus() 本身中完成的。

我们仍然可以将参数命名为“logger”，以期揭示我们的意图。不过好像有点弱。

相反，我会选择请求一个 IInvoiceLogger （正如我们在代码示例中所做的那样）并让 IInvoiceService 实现该接口。客户端代码可以简单地将其单个 IInvoiceService 用于所有请求任何此类非常特殊的发票固有“迷你服务”的 Invoice 方法，而方法签名仍然充分明确他们的要求。

我注意到我没有明确提及存储库。好吧，记录器是或使用存储库，但让我还提供一个更明确的示例。如果仅在一两个方法中需要存储库，我们可以使用相同的方法。

public class Invoice
{
    public IEnumerable<CreditNote> GetCreditNotes(ICreditNoteRepository repository)
    { ... }
}

事实上，这为一直麻烦的延迟加载提供了一种替代方案。

更新：出于历史目的，我保留了下面的文本，但我建议 100% 避免延迟加载。

对于真正的基于属性的延迟加载，我当前使用构造函数注入，但是以一种持久性无知的方式。

public class Invoice
{
    // Lazy could use an interface (for contravariance if nothing else), but I digress
    public Lazy<IEnumerable<CreditNote>> CreditNotes { get; }

    // Give me something that will provide my credit notes
    public Invoice(Func<Invoice, IEnumerable<CreditNote>> lazyCreditNotes)
    {
        this.CreditNotes = new Lazy<IEnumerable<CreditNotes>>() => lazyCreditNotes(this));
    }
}

一方面，从数据库加载 Invoice 的存储库可以自由访问加载相应贷方票据的函数，并将该函数注入到 Invoice 中。

另一方面，创建实际new Invoice 的代码将仅传递返回空列表的函数：（

new Invoice(inv => new List<CreditNote>() as IEnumerable<CreditNote>)

自定义 ILazy 可以让我们摆脱对 IEnumerable 的丑陋转换，但这会使讨论变得复杂。）

// Or just an empty IEnumerable
new Invoice(inv => IEnumerable.Empty<CreditNote>())

我很高兴听到您的意见、偏好和改进！

Answer 5

为什么要分离数据访问？

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

• 你希望领域模型和代码之间保持紧密联系
• 分离技术问题有助于证明模型对于实现是实用的
• 你希望通用语言渗透到系统的设计

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

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

另一方面，开发人员在领域模型中引入过多的技术问题也可能导致这种分歧。

因此，您可以考虑实践关注点分离（例如持久性）可以帮助防止这些设计和分析模型出现分歧。如果感觉有必要将持久性之类的东西引入模型中，那么这是一个危险信号。也许该模型不适合实施。

引用：

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

按照我的解释，如果您最终使用更多行代码来处理数据库访问之类的事情，那么您就会失去这种沟通能力。

如果访问数据库的目的是检查唯一性之类的事情，请查看：

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

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

下的“所有规则均是” t 创建相等”

和

采用域模型模式

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

下的“不使用域模型的场景”，涉及同一主题。

如何分离数据访问

通过接口加载数据

“数据访问层”已通过接口进行抽象，您可以调用该接口来检索所需的数据：

var orderLines = OrderRepository.GetOrderLines(orderId);

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

优点：该接口分离出“数据访问”管道代码，使您能够仍然编写测试。数据访问可以根据具体情况进行处理，从而获得比通用策略更好的性能。

缺点：调用代码必须假设哪些内容已加载，哪些内容尚未加载。

假设出于性能原因，GetOrderLines 返回具有 null 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 用于构建聚合，然后聚合执行其工作。

优点：允许每个用例使用自定义代码，从而实现最佳性能。符合接口隔离原则。没有复杂的代码要求。聚合单元测试不必模仿加载策略。通用加载策略可以用于大多数情况（例如“加载全部”策略），并且可以在必要时实施特殊加载策略。

缺点：更改域代码后，开发人员仍然需要调整/审查获取策略。

使用获取策略方法，您可能仍然会发现自己正在更改自定义获取代码以适应业务规则的变化。这不是一个完美的关注点分离，但最终会更易于维护，并且比第一个选项更好。获取策略确实封装了数据加载的方式、时间和地点。它具有更好的关注点分离，而不会失去像一刀切的延迟加载方法那样的灵活性。

Answer 6

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

我能想到的原因是：

• 关注点分离（实体应该与它们的持久化方式分开。因为根据使用场景，可能有多种策略来持久化同一实体）从
• 逻辑上讲，实体可以在一个级别低于存储库运行的级别。较低级别的组件不应该了解较高级别的组件。因此条目不应该具有存储库方面的知识。

Answer 7

实体仅捕获与其有效状态相关的规则。其中的数据有效吗？他们里面的数据能这样改变吗？

聚合根对一组实体执行相同的操作。汇总的数据有效吗？聚合中的数据能这样改变吗？

领域服务捕获有关跨实体或聚合的更改的规则。我们可以这样改变X和Y吗？

所有这些都不需要访问存储库或基础设施。您所做的是应用程序服务将提供一个域用例，对于该用例，应用程序服务将从存储库收集所有所需的数据，这将返回您的域实体和/或聚合根及其值对象。实体/聚合根和值对象将验证它们在由存储库创建时处于良好状态。然后，应用程序服务将使用这些实体的组合（其中一些可能是聚合根）来执行域用例。如果域用例需要更改 X、Y 和 Z，则应用程序服务将询问 X、Y 和 Z 实体/聚合根当前用例请求是否可以对 X、Y 和 Z 进行更改，如果可以，如何进行是否应该制作。最后，应用程序服务会将这些更改提交回存储库。

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

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

最后，应用程序服务还可以使用其他应用程序服务，可以是共享有界上下文中的其他微服务，这意味着它们共享相同的域模型，或者它可以跨其他有界上下文中的应用程序服务这样做，其中如果您也想在自己的有界上下文的域模型中对它们进行建模，那么您会在某种程度上将其他有界上下文视为存储库。应用程序服务与另一个有界上下文通信以获取有关该其他上下文的信息，然后它使用自己的实体和 VO 以及聚合在自己的域模型中创建该信息的表示，这将再次在其上下文中验证该状态。同样，您可以通过要求其他有界上下文进行相应更改来将对域模型的更改提交给其他有界上下文。所有这些都可以通过直接方法调用、远程 API 调用、异步事件、共享内核等来实现。

要回答为什么会这样，那是因为重点是构建可以随着时间的推移而发展的软件，而不会变得更慢对其进行更改并添加/修改其行为，同时保留其当前功能的正确性。做到这一点的一个好方法是在一个地方进行更改，而不会破坏其他地方的东西。这就是有界上下文存在的原因，更改已经限制在每个上下文中，因此一个上下文中的更改不太可能破坏另一个上下文。这也是域模型验证域状态的所有更改的原因，因此您不能以破坏状态的其他用法的方式更改部分状态。这就是为什么使用聚合，以在需要聚合的事物之间维持变化边界，而在不需要聚合的事物之间显然没有变化边界。最后，通过拥有具有域模型和域服务的整个域层，不依赖于任何基础设施，例如存储库（以及数据库），对数据库或存储库的更改也将无法破坏您的域模型或服务。

PS：另请注意，我宽松地使用了“状态”一词。它不必是静态值；状态可以是一些动态计算或规则的应用，在请求时生成状态。您可以在某个实体上拥有类似 TotalItemsCount 的内容，当询问该实体当前的 TotalItemsCount 是多少时，它会计算它。同样，实体将确保返回有效状态，这意味着它将知道如何正确计算总数，并确保返回的是totalItemsCount 域规则的正确应用。

Answer 8

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

都是老东西了埃里克的书让这件事变得更加热闹。

对于其背后的推理有什么好的解释吗？

原因很简单——当人类面对模糊相关的多个情境时，人类的思维就会变得脆弱。它们会导致歧义（南/北美洲中的美国意味着南/北美洲），每当思想“触及”它时，歧义就会导致不断的信息映射，这总结为低生产力和错误。

业务逻辑应该尽可能清晰地反映。外键、规范化、对象关系映射来自完全不同的领域——这些东西与技术、计算机相关。

打个比方：如果你正在学习如何手写，你不应该被理解笔是在哪里制造的、为什么墨水会留在纸上、纸是何时发明的以及中国其他著名的发明是什么所困扰。

编辑：澄清一下：我不是在谈论将数据访问与业务逻辑分离到单独层的经典 OO 实践 - 我是在谈论 DDD 中的具体安排，实体不应该说话完全到数据访问层（即它们不应该保存对存储库对象的引用）

原因仍然与我上面提到的相同。这里只是更进一步。如果实体可以（至少接近）完全无知，为什么它们应该部分持久无知？我们的模型所持有的与领域无关的关注点更少——当我们的大脑必须重新解释它时，它会获得更多的喘息空间。

Answer 9

Vernon Vaughn 简单地给出了一个解决方案：

使用存储库或域服务提前查找依赖对象
调用聚合行为。客户端应用程序服务可以
控制这个。

Answer 10

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

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

我认为将数据访问（又名“存储库”）与业务逻辑分离是其中之一，尽管《领域驱动设计》一书已经多次重新发明，但它却带来了很多“噪音”。

我目前使用 3 层（GUI、逻辑、数据访问），就像许多开发人员所做的那样，因为它是一项很好的技术。

将数据分离到存储库层（又名数据访问层）可能被视为一种良好的编程技术，而不仅仅是需要遵循的规则。

与许多方法一样，您可能希望从不实施开始，并最终在理解它们后更新您的程序。

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

Answer 11

引用 Carolina Lilientahl 的话，“模式应该防止循环”https://www.youtube.com/watch ?v=eJjadzMRQAk，她指的是类之间的循环依赖关系。对于聚合内部的存储库，出于对象导航的便利性而存在创建循环依赖关系的诱惑，这是唯一的原因。 Prograhammer 上面提到的模式是 Vernon Vaughn 推荐的，其中其他聚合由 ids 而不是根实例引用（该模式有名称吗？）建议了一种可能引导其他解决方案的替代方案。

类之间循环依赖的示例（坦白）：

(Time0)：两个类 Sample 和 Well 相互引用（循环依赖）。 Well 指的是 Sample，Sample 指的是 Well，为了方便起见（有时循环样品，有时循环板中的所有孔）。我无法想象样本不会引用它所在的井的情况。

（时间 1）：一年后，实施了许多用例......并且现在存在样品不应引用回其所在孔的情况。工作步骤中存在临时板。这里的孔指的是样品，而样品又指另一个板上的孔。因此，当有人尝试实现新功能时，有时会出现奇怪的行为。需要时间去渗透。

我也得到了这篇文章提到的帮助上面关于延迟加载的负面影响。

Answer 12

参加聚会已经很晚了，但我会给我 2 美分。

从性能的角度来看，在域模型中抽象 REST API 操作的存储库和域服务可能是一场重大灾难。我认为域服务（尽管红皮书中另有说明！）和聚合都不应该尝试使用它们，并且这两个概念应该只保留在应用程序服务领域，它唯一的责任是无论您使用 Layers 还是 Hexagon（端口和适配器），都可以与外界通信。

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

1. 防止任何类型的性能瓶颈。
2. 防止域模型内任何类型的全局访问（存储库是全局的）。

构建正确的对象图，在应用程序服务中使用正确的获取策略，并将纯内存中的对象传递给富域模型。延迟加载会潜入您的代码并给您带来最严重的伤害。

Answer 13

在理想世界中，DDD 提出实体不应该引用数据层。但我们并不生活在理想的世界中。域可能需要引用其他域对象来实现业务逻辑，而它们可能不具有依赖关系。实体出于只读目的引用存储库层以获取值是合乎逻辑的。