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