在進入細節之前，讓我們看看一些總體的 DDD 原則

數據庫提供者 / ORM 無關性

領域和應用程序層應該與 ORM / 數據庫提供程序 無關。它們應該只依賴于 Repository 接口，而 Repository 接口不使用任何 ORM 特定的對象

下面說明這一原則的主要原因:

1. 為了使您的 領域/應用程序 獨立于 基礎設施，因為基礎設施可能在將來更改，或者您可能需要支持第二種數據庫類型
2. 通過將基礎設施細節隱藏在存儲庫后面，使您的 領域/應用程序 專注于業務代碼。
3. 使您的自動化測試更容易，因為在這種情況下您可以模擬存儲庫

根據這一原則，解決方案中的任何項目都沒有引用EntityFrameworkCore項目，除了啟動應用程序

關于數據庫無關性原則的探討

上述原因1,深深地影響了你的領域對象設計(尤其是實體關系)和應用程序代碼。假設您正在使用 EF Core 與關系數據庫。如果你想讓你的應用在以后切換到 MongoDB ，你就不能使用一些非常有用的 EF Core 特性

例如:

• 你不能假設 Change Tracking，因為 MongoDB 不能這樣做。因此，您總是需要顯式地更新已更改的實體。
• 您不能對實體中的其他聚合使用 導航屬性 (或集合)，因為這對于文檔數據庫是不可能的。更多信息請參見“規則:僅根據Id引用其他聚合”部分

如果你認為這些功能對你很重要，并且你永遠不會偏離 EF Core，我們相信這一原則是值得延伸的。我們仍然建議使用 Repository 模式來隱藏基礎設施細節。但你可以假設你在設計實體關系和編寫應用程序代碼時使用的是 EF Core。你甚至可以從你的應用層引用 EF Core 的 NuGet 包 來直接使用異步LINQ擴展方法，比如ToListAsync() (參見 Repositories 文檔中的 IQueryable & Async 操作部分來獲取更多信息)

表現層技術無關性

表現層技術(UI框架)是真實應用程序中變化最大的部分之一。在設計領域層和應用層時，完全不考慮表現層技術/框架是非常重要的。這一原則相對容易實現，而ABP的啟動模板使之更加容易

在某些情況下，您可能需要在應用程序層和表示層中有重復的邏輯。例如，您可能需要在兩個層中重復驗證和授權檢查。UI層中的檢查主要是為了用戶體驗，而應用程序層和領域層中的檢查是為了安全性和數據完整性。這是非常正常和必要的

關注狀態變化,而不是報告

DDD關注領域對象如何變化和交互;如何創建實體并通過保持數據完整性/有效性和實現業務規則來更改其屬性

DDD忽略報告和大規模查詢。這并不意味著它們不重要。如果您的應用程序沒有花哨的儀表板和報告，誰會使用它呢?然而，報告是另一個主題。您通常希望使用SQL Server的全部功能，甚至使用單獨的數據源(如ElasticSearch)來進行報告。您將編寫優化的查詢、創建索引甚至存儲過程(!)。您可以自由地做所有這些事情，只要您不將它們影響到您的業務邏輯