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

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

域服务捕获关于实体或聚合之间更改的规则。我们可以这样改变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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这是一个非常好的问题。我期待着就此进行一些讨论。但我想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的生命周期中，这可以为模型增加更多的复杂性。

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

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

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

我能想到的原因是:

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

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

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