ABP框架領域層

領域層

•實體

•倉儲

•領域服務

•工作單元（下期）

•領域事件（事件匯流排）（下期）

•實體是DDD（領域驅動設計）的核心概念之一。

•Eirc Evans是這樣描述的實體的：“它根本上不是通過屬性定義的，而是通過一系列連續性(continuity)和標識(identity)定義的”。

•因此，實體都有Id屬性並且都儲存到資料庫中。

•一個實體一般會對映到資料庫的一張表。

在ABP中，實體派生自Entity類，Entity預設是int(int32)

對倉儲的定義：

•位於領域層和資料對映層之間，使用類似集合的介面來訪問領域物件。

•在實踐中，倉儲是執行領域物件（實體和值物件）的資料庫操作。一般地，一個分離的倉儲用於一個實體（或者聚合根）。

IRepository介面

在ABP中，一個倉儲類應該實現一個IRepository介面。為每一個倉儲定義一個介面是一個好的做法。

IRepository介面：查詢

獲得單個實體

IRepository介面：查詢

獲得多個實體

IRepository介面：插入

獲得多個實體

注：Insert、InsertOrUpdate 方法不會即時執行到資料庫。只有帶 AndGetId 的方法才會即時執行到資料庫。

 當工作單元完成時才統一執行到資料庫。

IRepository介面：更新、刪除

注：更新、刪除方法不會即時執行到資料庫。

 當工作單元完成時才統一執行到資料庫。

IRepository介面：使用

IRepository介面：最佳實踐

•倉儲類應該是無狀態的。這意味著，你不應該定義倉儲級別的狀態物件，而且一個倉儲方法呼叫不應該影響其他的呼叫。

•自定義倉儲方法不應該包含業務邏輯或者應用邏輯，而應該只執行資料相關的或者orm特定的任務。

•當倉儲使用依賴注入時，給其他服務定義更少的或者不要定義依賴。

領域服務（或DDD中的服務）用於執行領域操作和業務規則。Eric Evans描述了一個好的服務應該具備下面三個特徵：

1.和領域概念相關的操作不是一個實體或者值物件的本質部分。

2.介面定義在領域模型其他元素的條款中。

3.操作是無狀態的。

跟獲得或返回一個資料傳輸物件的應用服務方法（DTO）不同，領域服務獲得或者返回一個領域物件（比如實體或值型別）。

一個領域服務可以用於應用服務，也可以用於其他的領域服務，但不能直接用於展現層，服務層才直接用於展現層。

IDomainService介面和DomainService類

1.ABP定義了IDomainService介面，所有的領域服務都按照慣例實現了該介面。當實現時，領域服務會以transient自動註冊到依賴注入系統。

●

2.此外，領域服務（可選地）可以從DomainService類繼承。因此，它可以使用一些繼承的屬性，比如logging，本地化等等。當然，如果沒有繼承，如果需要的話也可以注入這些屬性。

討論:

為什麼不使用應用服務實現領域服務中的邏輯呢？

我們可以簡單地說，它不是應用服務要乾的活。因為領域邏輯不是一個用例（use-case），而是一個 業務操作。我們可以在不同的用例中使用相同的“將一個任務派給一個人”的邏輯。比如說我們以後會更新這個任務，並且將這個任務派給其他人。

因此，我們可以使用相同的領域邏輯，這個邏輯就是“將一個任務派給一個人”，我們不用考慮這個具體的人和具體的任務。此外，我們可能有兩個不同的UI（一個移動端應用和一個web應用）來共享相同的領域。

如何強制使用領域服務：

開發這個應用服務的開發者可能不知道存在一個TaskDomainService，而且可以直接將給定的 PersonId設定給任務的 AssignedPersonId。那麼，如何阻止他這樣做呢？

回顧

•實體：定義實體常用的幾種基類  Entity、CreationAuditedEntity、AuditedEntity、FullAuditedEntity、IPassivable、AggregateRoot

•倉儲：倉儲提供資料層常用的操作方法，倉儲的定義與使用方式，倉儲使用的最佳實踐和建議。

•領域服務：領域服務存在的意義、職責，如何定義一個領域服務。