這里的土牛是指abp的作者，土耳其人，簡稱“土?！?#xff0c;前兩天看了他分享的ppt，這里做個小筆記。

架構分層

圖一（abp作者）

圖二（clean架構）

圖三（在朋友圈看到的）

每種架構沒有好壞，只要是流行的，適合自己的就好。一種架構不管是否完全運用DDD思想，不重要，合理的分層是必須的！

• 表現層

• 應用層（用例）

• 領域層

• 基礎設施層

領域驅動的核心構件

最佳實踐

Repositories 原則

• repository 是一個類似于集合的接口，可與數據庫交互以讀取和寫入實體

• 在domain layer定義接口，在infrastructure中實現

• 不包含domain 邏輯

• Repository?接口應獨立于數據庫/ ORM

• 為聚合根而非實體創建repositories

Application Services 原則

• 實現應用程序的用例（應用邏輯）

• 不實現核心domain邏輯

• 獲取并返回數據傳輸對象（DTO），而不是實體（entities）

• 在內部使用領域服務，實體，倉儲，和其他領域對象。

Application Services

通用DTO原則最佳實踐

• 應該序列化

• 應該有一個無參數的構造函數

• 不應該包含業務邏輯

• 不要從實體繼承！不要引用實體！

Input DTO 最佳實踐

• 僅定義用例所需的屬性

• 不要在多個用例（服務方法）中重復使用相同的輸入DTO。

例如：

• ID 在創建的時候不會使用！創建和修改不要共享相同的dto！

• 密碼在更改和ChangeUserName不會使用！

另外兩個最佳實戰

• 僅實現形式驗證（可以使用數據注釋屬性）

• 不包括域驗證邏輯（例如：唯一用戶名約束）

Application Services

Output DTO 建議

• 保持輸出DTO文件數量最小。盡可能重復使用（不能把輸入DTO作為輸出DTO）。

• 可能包含比客戶需求更多的屬性

• 創建和更新方法返回實體DTO。

• 例外：性能至關重要的地方，尤其是對于大型結果集。

vs

Application Services 對象映射

• 使用自動對象映射庫（但是，請小心–啟用配置驗證）

• 不要將輸入DTO映射到實體。

• 將實體映射到輸出DTO

Multiple Application Layers 多個應用層

• 為每種應用程序類型創建單獨的應用程序層。

• 使用單個領域層 共享核心域邏輯。

總結

以上是生活随笔為你收集整理的跟着“土牛”学架构知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。