我正在使用具有以下层的实体框架 6 开发 WinForms 应用程序：
- 介绍
- 应用
- 域
- 基础设施
当用户从 UI 单击保存按钮时，它会调用应用程序层中的应用程序服务并传入请求。 然后，应用程序服务使用请求调用域服务。 域服务调用域模型中的多个实体，以对请求中使用的数据执行验证。
域模型中的一个或多个验证需要来自存储库的信息，以确定从表示层接收的请求中的数据是否符合某些业务规则。
我正在考虑两种选择来解决这个问题。
-
让应用程序服务从中检索所需的信息存储库进行验证，并将这些值传递到域服务，它将调用域模型和实体验证规则和值的传入请求。 然后让应用程序服务在域服务具有完成验证，这将导致返回控制权返回到同步等待的应用程序服务完成验证。 如果我这样做，那么域层将没有直接或间接（注入）对存储库的引用。如果我这样做，域服务的单元测试会更容易因为没有注入任何内容来执行验证。它需要的一切都已经传递了。缺点是一些业务知识被放入应用程序服务中，因为现在它需要知道要检索哪些存储库信息请求的验证。
-
调用域服务以验证请求时，将应用程序服务的实例注入其中。 域然后，服务可以使用注入的应用程序服务，其服务协定在域层。一旦所有信息都可用，它就会被传递根据需要对各种实体进行验证规则和值。一次验证完成，域服务使用注入的应用程序服务。 域服务完成后并退出，它将保存操作的状态返回到一直在等待验证的应用程序服务完成。 然后，外部等待应用程序服务可以返回保存到 UI 的结果。 我在这里的一个担忧是，当单元测试域服务我将不得不模拟注入的应用服务。
哪种选择或其他行动方案会更好？提前谢谢。
"是否应将应用程序服务注入域服务"
不，绝不！
从应用程序服务解析数据并将其传递给域服务通常没问题，但如果您认为域逻辑泄漏，则您可以应用接口隔离原则 （ISP），并根据查询"所需数据"所需的协定在域中定义接口。在您的存储库或任何其他可以完成任务的对象上实现该接口，并将其注入到您的域服务中。
例如（伪代码）
//domain
public interface WantedDataProvider {
public WantedData findWantedData(...) {}
}
public class SomeDomainService {
WantedDataProvider wantedDataProvider;
}
//infrastructure
public class SomeRepository implements WantedDataProvider {
public WantedData findWantedData(...) {
//implementation
}
}
编辑：
我有一个带有员工姓名的请求聚合根。一条规则是 员工必须是全职员工，而不是承包商
如果聚合上已存在用于执行验证的信息，则还可以将此 AR 用作其他 AR 的工厂。假设员工持有其合同类型...
Employee employee = employeeRepository.findById(employeeId);
Request request = employee.submitRequest(requestDetails); //throws if not full time
requestRepository.add(request);
请注意，除非更改聚合边界，否则此处只能使不变性最终保持一致，但与其他解决方案相同。
当域中的重要流程或转换不是实体或值对象的自然职责时，请将操作作为声明为服务的独立接口添加到模型中。根据模型的语言定义接口，并确保操作名称是通用语言的一部分。使服务无状态 - 埃文斯，蓝皮书
不要过分倾向于将领域概念建模为服务。只有在情况合适的情况下才这样做。如果我们不小心，我们可能会开始将服务视为我们的建模"银弹"。过度使用服务通常会导致创建Anemnic域模型的负面后果，其中所有域逻辑都驻留在服务中。- 弗农，红皮书
我试图通过大量引用来说明的是，您似乎将域服务视为您必须拥有的东西，而您绝对不必这样做。您的应用程序服务可以愉快地使用存储库来获取聚合，然后调用聚合根方法来执行必要的操作。聚合根负责通过在其中执行必要的验证来保护自己的不变量，并在出现任何问题时引发验证异常。
如果您绝对必须使用域服务，如果您做得对，这意味着您实现了洋葱体系结构，其中内层不知道外层，您的域服务将无法了解应用程序服务。但是，如果绝对必要，则可以将委托发送到域服务中，以执行应用程序服务所需的操作。但是，这种情况太复杂了，令人难以置信。看到您只需要验证，请阅读蓝色和红色书籍的引用部分并做出正确的决定。同样，DDD 中没有强制性域服务，这是常见的误解之一。