我會問你關於設計問題的觀點。在公共方法中檢查參數的先決條件
問題基本上如下：一個對象的公共方法應該總是檢查其輸入參數中的前提條件，還是更好地愛對調用者的責任和「相信流量」？
我不是在談論明顯的先決條件，如檢查null以避免空引用異常，但我指的是方法參數中的業務前提條件。這種典型的情況發生在DDD服務中，它對輸入參數執行某種驗證，並返回包含關於該驗證的反饋的對象。
作爲示例，考慮具有公開方法PerformCheck的類CheckPerson，其具有Person類型的單個參數。想象一下，有一條商業規則說這張支票對金髮人士來說沒有意義。
在我看來，這個檢查是重要的，方法名稱應該反映這個規則（如PerformCheckForNonBlondePerson）。
我應該添加這些檢查還是我應該相信呼叫者？
是的，你應該！
您需要區分輸入驗證和之間前提。業務規則，正如你所描述的那樣，可以同時應用於兩者。
輸入驗證發生在系統邊界。您希望在某些情況下輸入驗證失敗。發生這種情況時，您應該向客戶指出錯誤並提供有用的錯誤描述。
另一方面，前提條件是系統中某個方法（或整個組件）合同的一部分。你總是想要確保這份合同得到遵守，因爲你的實現可能會在其他方面表現不正確。在這裏，我們使用後衛來強制執行前提條件。一個守衛應該總是通過。如果沒有，它總是程序員錯誤（而不是用戶錯誤）。
@theDmi感謝您分享您的觀點。
我完全同意你的立場。
我目前工作的環境是一個由三人組成的團隊，實施一個大型應用程序，並將大量業務邏輯和領域規則考慮在內。
我不同意「信任流程並將責任委託給調用者」理念的主要原因是，這會迫使每位將要調用域服務的開發人員顯式讀取此類代碼一項服務以及對該代碼背後的業務需求有良好的瞭解。
在我看來，這是不現實的，而且這是一個容易出錯的過程。
大型應用程序中的域層被我們要編寫的每一個應用程序邏輯所調用，而將所有責任留給調用者在我看來都是太危險了。我們目前沒有使用任何類型的圖書館來執行先決條件檢查，但我知道有幾個選項:)
感謝您的回覆。查看我自己的答案，對您的答案進行擴展評論。祝你有美好的一天 ！ –