我会问你关于设计问题的观点。
问题基本上如下：对象的公共方法应该始终检查其输入参数中的前提条件，或者更好地对调用者负责，并且信任流程＆＃34; ？
我不是在谈论明显的前提条件，例如检查null以避免空引用异常，但我在方法参数中引用业务前置条件。这种情况通常发生在DDD服务中，它对输入参数执行某种验证并返回包含有关该验证的反馈的对象。
作为示例，请考虑具有公共方法CheckPerson且具有类型PerformCheck的单个参数的类Person。想象一下，有一条商业规则说这种检查对金发女郎没有意义。
在我看来，此检查很重要，方法名称应该反映此规则（类似PerformCheckForNonBlondePerson）。
我应该添加这些支票，还是应该信任来电者？
答案 0 :(得分：0)
是的，你应该！
您需要区分输入验证和前提条件。正如您所描述的那样，业务规则可以应用于两者。
输入验证发生在系统边界。在某些情况下，您希望输入验证失败。当发生这种情况时，您应该向客户端指出错误，并提供有用的错误描述。
另一方面，前提条件是系统中某个方法（或整个组件）合同的一部分。您始终希望确保遵守此合同，否则您的实施可能会表现不正确。在这里，我们使用 guards 来强制执行前提条件。守卫应该永远通过。如果没有，则始终是程序员错误（与用户错误相反）。
答案 1 :(得分：0)
@theDmi感谢您分享您的观点。
我完全同意你的立场。
我目前工作的情况是由三人组成的团队，实施一个包含大量业务逻辑和域规则的大型应用程序。
我不同意＆＃34; 的主要原因是信任流程并将责任委托给来电者＆＃34;哲学是，这迫使每个开发人员打算调用域服务，以明确地读取此类服务的代码，并充分了解该代码背后的业务需求。
在我看来，这是不现实的，而且这是一个容易出错的过程。
大型应用程序中的域层由我们要编写的每个应用程序逻辑调用，并且在我看来，对调用者的所有责任都是非常危险的。我们目前不使用任何类型的库来强制执行前提条件检查，但我知道有几种选择：）