這叫什麼類型的架構？
對於我目前正在開發的 Web 應用程序（ASP.NET MVC），我們有以下架構：
Data Access Layer: 將數據持久化到任意數據庫的邏輯Domain: 數據模型Service Layer：業務邏輯（如訂單處理、賬戶管理等）Controller：使用服務並向視圖提供/接收數據View：使用者的使用者界面本質上，我將
Model和 拆分為DAL,Service Layer和Domain。我覺得把所有的邏輯都塞程序式碼裡Model讓我的程式碼變得過於復雜。此外，我覺得它讓我可以清晰地表達我的業務邏輯，而不會讓控制器做太多的工作。**那麼我的問題是：**這種類型的架構叫什麼？
作為第二個問題：這種架構有意義嗎？如果沒有，我做錯了嗎？
根據域和服務層的薄/厚，您在 DDD 方面處於正確的軌道上。DDD 說知識（即業務邏輯）應該被壓縮到領域模型中。將數據訪問問題移至 DAL 符合 DDD，但我認為將業務邏輯移出服務層則不然。如果您有一個薄的域“數據模型”層（主要用於實體）和一個厚的服務層（主要用於“業務邏輯”），您可能有一個貧血的域。
此外，從技術上講，DDD 中沒有“服務層”。可能有一個“應用程序層”，但它應該很薄，並且只負責應用程序流/管理域類生命週期。這本質上是控制器在 .NET MVC 中所做的，在 web http 的上下文中管理應用程序流。
如果在模型中填充所有邏輯會使您的程式碼過於復雜，那麼我很想听聽您所說的“過於復雜”的含義的範例。您可能正在正確地建模一個複雜的域，或者您可能已經使用 DDD 模式來簡化事情。我想說，正如您在問題中列出的那樣，拱門不是 DDD。我只稱它為“分層架構”，但那是因為我只在談論物理拱門時更喜歡使用“層”一詞。但是，您的邏輯架構是分層的。
我真的很喜歡 Darin 在他的回答中與 Onion arch 相關聯。我正在成為它的忠實粉絲，而且我發現它根本不是 DDD 獨有的。如果你的程式碼使用依賴注入來解決執行時實現的介面依賴，你可能有一種洋蔥拱的形式。例如，您是否在 DAL 中定義了任何介面？這些介面的實現是否在執行時解決？
這是我開始在新項目中使用的拱門範例。這是洋蔥+ DDD的組合：
API項目/程序集：所有其他層使用的通用介面、枚舉、類和擴展方法。不必與域分開，但可以。Domain項目/程序集：所有實體和業務邏輯。僅取決於API。使用工廠、服務、規範、儲存庫等 DDD 模式。還包含更多未在 API 中定義的特定於域的介面。Impl項目/程序集：在API和中定義的介面的實現Domain。這是實現 EF DbContext 以及日誌記錄、電子郵件發送等的地方。所有這些實現都是依賴注入的，因此從技術上講，您可以擁有多個 Impl 項目/程序集。UI項目/程序集：這是 MVC 項目。控制器直接使用域表面，不通過應用程序或服務層。工廠、服務、儲存庫等中的任何介面依賴項都由控制器使用 MVC IoC（建構子注入）注入到域中。我在核心放置了一個 API 層，但您可以將 API 和域項目合併為一個。無論哪種方式，洋蔥的大肉部分是域，它有內部分層。例如，服務可能依賴於工廠，工廠依賴於儲存庫，而儲存庫又依賴於實體。
Impl 項目就是您在巴勒莫圖中看到的“基礎設施”洋蔥皮。它與 UI 一起位於外部邊緣，不包含特定領域的知識。它知道如何發送電子郵件、使用 EF 儲存/檢索數據等。如果您願意，您可以擁有超過 1 個這些 - 例如 1 個用於數據訪問的 Impl、1 個用於處理郵件的 Impl 等。
MVC 有控制器和視圖，專注於 UI 和 Web 應用程序流。任何需要特定領域知識的東西都被委託給領域，領域類是注入控制器的建構子。這意味著域類中的任何建構子注入介面都由 IoC 容器自動解析。
最後一點，針對 API 和域類中定義的介面進行程式意味著您可以將域項目與 MVC 項目分開進行單元測試。