丰富领域模型的接口答案

【问题标题】：Interfaces for Rich Domain Models丰富领域模型的接口
【发布时间】：2015-03-27 20:58:11
【问题描述】：

在单元测试期间（例如，在测试使用该模型的服务时），富域模型是否应该有接口来帮助隔离？

或者是否应该在任何相关的单元测试中涉及富域模型行为？

编辑：

通过富域模型，我特别指的是包含逻辑（即非贫血）的域实体。

【问题讨论】：

【解决方案1】：

通常，域模型是您应该与其他任何事物保持隔离的部分。领域模型可以使用接口，以便与外部系统等隔离。

但是，在最常见的场景中，域模型是您试图保护其免受外部系统、UI 逻辑等不断恶化的影响 - 而不是相反。

因此，几乎没有理由将接口放在域模型上。

【讨论】：

我理解您的观点，我更多地指的是应用程序或域服务，例如它们可能正在编排许多域模型对象。是否应该为了测试服务逻辑而模拟掉这些对象的行为？
@BrettPostin 这些服务与域模型有何不同？他们不是描述了领域模型的行为吗？
抱歉，我可能应该更具体一些，我的意思是富域实体。在对使用它们的其他类进行单元测试时，是否应该模拟它们的逻辑？
@MarkSeemann 你如何编写孤立/孤立的测试（在 J.B. Rainsberger 的“集成测试是一个骗局”论点或 Jay Fields 的“有效地使用单元测试”的意义上，即伪装几乎所有合作者）为您的域对象？如果你想走那条路，你需要接缝。例如，在 C# 中，您不能只提供一个假的协作者类，而没有“虚拟化”所有事物或没有适当的接口。我知道这可能使孤立测试有点过头了，但我一直想知道这个问题。想法？
@prgmtc 前段时间我在同一条船上，直到我意识到在域模型中，被测系统（Rainsberger 术语中的“星”）是整个聚合，而不仅仅是一个对象.聚合只与自身对话，并且大多数有意义的逻辑在于其入口点发生的不变量，聚合根级别。尝试单独测试每个实体就像尝试单独测试对象的私有方法一样。

【解决方案2】：

您绝对应该在单元测试中涉及域模型行为。嘲笑这部分绝对没有意义。你真的应该只是在模拟外部系统。

【讨论】：

【解决方案3】：

富域模型应该有接口

我会说不，因为

域行为发生在分隔良好的气泡内。给定的命令会触发单个聚合中的更改。从概念上讲，您不必隔离它，因为它基本上只是自言自语。它也可能向外界发出消息（事件），但测试不需要域实体本身是可模拟的。
具体来说，域实体（或值对象）的行为是流动的——它全部发生在内存中，不应该直接调用较低级别的 I/O 绑定操作。只要被测系统是一个小的准备好的对象集群（聚合，也许是调用它的东西），不在测试中模拟东西就不会影响性能。
域模型是具体概念的领域。反映在您的实体或值对象类/方法名称中的通用语言术语通常是平淡无奇的。那里不需要抽象和多态——这就是接口或抽象类的用途。该领域不是关于提供服务的通用合同或接口，而是关于问题领域中发生的现实世界任务。

【讨论】：