用戶端驗證（呈現層中的驗證）
即使事實來源是領域模型，而且最終您必須在領域模型層級進行驗證，驗證仍然可以在領域模型層級（伺服器端）和UI（客戶端）處理。
客戶端驗證是用戶的絕佳便利性。 這可節省他們本來需要花在伺服器回傳時可能出現驗證錯誤的等待時間。 就商業而言，百分之一秒的差距每天乘以數百次，累積起來會導致大量的時間花費、成本支出和挫折感。 直接且立即的驗證可讓使用者更有效率地工作，併產生更好的品質輸入和輸出。
如同檢視模型和領域模型不同，檢視模型驗證和領域模型驗證可能類似，但用途不同。 如果您擔心 DRY（Don't Repeat Yourself 原則），請考慮在這種情況下，程式碼重複使用可能也意味著耦合。 在企業應用程式中，不讓伺服器端和用戶端耦合，比遵循 DRY 原則更為重要。
即使使用客戶端驗證，您也應該一律在伺服器程式代碼中驗證命令或輸入 DTO，因為伺服器 API 是可能的攻擊媒介。 通常，執行兩者都是最佳選擇，因為如果您有用戶端應用程式，從UX的觀點來看，最好是主動且不允許使用者輸入無效的資訊。
因此，在用戶端程序代碼中，您通常會驗證 ViewModels。 您也可以在將 DTO 或命令傳送至服務之前，先驗證客戶端輸出 DTO 或命令。
用戶端驗證的實作取決於您要建置的用戶端應用程式類型。 如果您在 MVC Web 應用程式中使用 .NET 大部分程式碼來驗證資料，與在 JavaScript 或 TypeScript 中處理驗證程式碼的 SPA Web 應用程式，情況會有所不同。
其他資源
ASP.NET Core 應用程式中的驗證
SPA Web 應用程式的驗證 （Angular 2， TypeScript， JavaScript， Blazor WebAssembly）
驗證。 Breeze 文件。
https://breeze.github.io/doc-js/validation.htmlASP.NET Core Blazor 表單和輸入元件 \ </aspnet/core/blazor/forms-and-input-components>
總而言之，這些是驗證最重要的概念：
實體和聚合應維持自身的一致性，且「一律有效」。 匯總根負責相同匯總內的多實體一致性。
如果您認為實體需要進入無效狀態，請考慮使用不同的物件模型，例如，使用暫時的 DTO，直到您建立最終網域實體為止。
如果您需要建立數個相關物件，例如匯總，而且只有在建立所有對象之後才有效，請考慮使用 Factory 模式。
在大部分情況下，在用戶端中具有備援驗證是不錯的，因為應用程式可以是主動式的。
