领域模型应该如何耦合？所有聚合根都应该是接口吗？
我们终于构建了一个领域模型。域模型包括用于将域对象松散耦合到持久性的接口。然而，我想知道域模型对象之间应该如何耦合。
订单是否指向客户或ICustomer？
这篇文章提到了问题积极地解耦对象，并且似乎不鼓励“过度使用[接口]”。然而，我不知道如何真正对我的域实体进行单元测试，除非我可以模拟它们所依赖的其他实体，这需要松散耦合。
我也不确定想要一个可以交换各个部分的域模型是否现实。
We're finally building a domain model. The domain model includes interfaces for loosely coupling domain objects to persistence. I'm however wondering how coupled the domain model objects should be to each other.
Does Order point to a Customer or to an ICustomer?
This post mentions problems with aggressively de-coupling objects and seems to discourage "going overboard with [interfaces]". I however don't see how I can truly unit test my domain entities unless I can mock the other entities they depend on, which requires loose coupling.
I'm also uncertain about how realistic it is to want a domain model in which pieces could be swapped out.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当协作者满足以下条件时，我不介意在单元测试中使用具体协作者：
1）拥有一套全面的单元测试，明确指定其行为。
2）安排起来并不困难。
3) 不利用外部资源（或违反任何这些相关准则）。
我们一直使用框架类（例如
DateTime或string）来执行此操作 - 除非聚合的子级异常复杂，否则您也应该能够信任它。I don't mind using concrete collaborators in unit tests when the collaborator:
1) Has a comprehensive set of unit tests that clearly specifies its behavior.
2) Isn't difficult to arrange.
3) Doesn't utilize external resources (or break any of these related guidelines).
We do this all the time with framework classes (say,
DateTimeorstring) - unless an aggregate's child is unusually complex, you should be able to trust it too.持久性持久您的对象。它知道你的对象以便持久保存它们。将持久性与模型分离不会给你带来任何好处。领域中的任何变化都必须反映在持久层中。
在进行 DDD 时，您与领域专家一起确定通用语言，然后用代码表示。我还没有看到领域专家提到接口。通过识别领域中的正确概念来解耦模型中的 AR。您可能为某些域服务定义了接口，但请确保它们是您域中真正的服务提供者，而不是您错过的一些概念。
你说得对，这不现实。您可能会交换某个服务提供商的实现，但是 AR 中的实体呢？我不这么认为。
The persistence persists your objects. It knows your object in order to persist them. Decoupling the persistence from the model does not give you anything. Any change in the domain will have to be reflected in the persistence layer,
When doing DDD you work with the domain expert to identify the ubiquitous language, which you then represent in code. I have yet to see a domain expert mentioning an interface. Decouple the ARs in your model by identifying the right concepts in your domain. You might have interfaces defined for some domain services, but make sure they are real service providers in your domain and not some concepts you missed.
You are right, it's not realistic. You might swap the implementation for a certain service provider, but entities in an AR? I don't think so.
在进行 DDD 时，您不想“真正解耦实体”。您应该首先将域模型划分为应该解耦的聚合。在聚合内部，不需要模拟任何东西，因为聚合应该被视为单元测试的“单元”。
此外，将尽可能多的行为移至值对象将帮助您使域模型可测试，因为值对象（根据定义，它们是不可变的）非常容易测试。
When doing DDD you don't want to 'truly decouple entities'. You should start by partitioning your domain model into Aggregates which should be decoupled. Inside Aggregates there is no need to mock anything because an Aggregate should be treated as a 'unit' for unit tests.
Also, moving as much behavior as possible to Value Object will help you make your domain model testable as Value Objects (which are, by definition, immutable) are very easy to test.