領域邏輯 & 應用邏輯

如前所述，領域驅動設計中的業務邏輯分為兩部分(層):領域邏輯和應用邏輯:

領域邏輯和應用邏輯.png

領域邏輯由系統的核心領域規則組成，應用邏輯實作應用特定的用例

雖然定義很明確，但實作起來可能并不容易，您可能無法決定哪些代碼應該位于應用程式層，哪些代碼應該位于領域層，本節試圖解釋其中的差異

多個應用程式層

當系統比較大時，DDD有助于處理復雜性，特別是，如果在一個領域中開發了多個應用程式，那么領域邏輯與應用程式邏輯的分離就變得重要得多，

假設您正在構建一個具有多個應用程式的系統

一個網站應用程式，用 ASP.NET Core MVC 構建，向用戶展示你的產品，這樣的網站不需要認證就可以看到產品，用戶只有在執行某些操作(比如將產品添加到購物車中)時才會登錄到網站，
一個后臺管理程式，使用 Angular UI 構建(使用REST APIs)，本應用被公司辦公人員使用來管理系統(如編輯產品描述)
一個移動應用程式, 與網站相比，它具有更簡單的UI，它可以通過 REST APIs 或其他技術(如TCP套接字)與服務器通信，

多個應用程式.png

每個應用程式都有不同的需求、不同的用例(應用服務方法)、不同的dto、不同的驗證和授權規則……等

如果將所有這些邏輯混合到單個應用程式層會使您的服務包含太多的邏輯,使代碼更難開發、維護和測驗，并導致潛在的bug

如果一個領域有多個應用程式:

為每個應用程式/客戶端型別創建單獨的應用程式層，并在這些單獨的層中實作應用程式特定的業務邏輯，
使用單個領域層共享核心領域邏輯，

這樣的設計使得區分領域邏輯和應用程式邏輯變得更加重要，

為了更清楚地了解實作，您可以為每個應用程式型別創建不同的專案(.csproj)，例如:

后臺管理應用: IssueTracker.Admin.Application & IssueTracker.Admin.Application.Contracts
公共網站應用: IssueTracker.Public.Application & IssueTracker.Public.Application.Contracts
移動應用: IssueTracker.Mobile.Application & IssueTracker.Mobile.Application.Contracts

案例

本節包含一些應用程式服務和領域服務示例，以討論如何決定將業務邏輯放置在這些服務中

示例:在領域服務中新建組織

public class OrganizationManager : DomainService
{
    //省略了依賴注入
    public async Task<Organization> CreateAsync(string name)
    {
        if(await _organizationRepository.AnyAsync(x => x.Name == name))
        {
            throw new BusinessException("IssueTracking:DuplicateOrganizationName");
        }

        await _authorizationService.CheckAsync("OrganizationCreationPermissin");

        Logger.LogDebug($"Creating organization {name} by {_currentUser.UserName}");

        var organization = new Organization();

        await _emailSender.SendAsync(
            "[email protected]",
            "New Organization",
            "A new organization created with name: " + name
        );

        return organization;
    }
}

讓我們一步一步地看看 CreateAsync 方法，來討論代碼部分是否應該放在領域服務中

正確: 它首先檢查重復的組織名稱，并在這種情況下拋出例外，這與核心領域規則有關，我們不允許重復名稱
錯誤: 領域服務不應該執行授權，授權應該在應用層中完成，
錯誤: 它記錄了包含當前用戶的用戶名的訊息，領域服務不應該依賴于當前用戶，即使系統中沒有用戶，領域服務也應該可用，當前用戶(會話)應該是一個與表示/應用層相關的概念，
錯誤: 它發送了關于這個新組織創建的電子郵件，我們認為這也是一個特定于用例的業務邏輯，您可能希望在不同的用例中創建不同型別的電子郵件，或者在某些情況下不需要發送電子郵件，

示例:在應用服務中新建組織

public class OrganizationAppService : ApplicationService
{
    //省略了依賴注入

    [UnitOfWork]
    [Authorize("OrganizationCreationPermissin")]
    public async Task<Organization> CreateAsync(CreateOrganizationDto input)
    {
        await _paymentService.ChargeAsync(
            CurrentUser.Id, 
            GetOrganizationPrice()
        );

        var organization = await _organizationManager.CreateAsync(input.Name);

        await _organizationManager.InsertAsync(organization);

        await _emailSender.SendAsync(
            "[email protected]",
            "New Organization",
            "A new organization created with name: " + input.Name
        );

        return organization; //!!!
    }

    private double GetOrganizationPrice()
    {
        return 42.0; //或者從其他地方獲取
    }
}

讓我們一步一步地看看 CreateAsync 方法，來討論代碼部分是否應該放在應用程式服務中

正確: 應用程式服務方法應該是作業單元(事務)，ABP的作業單元系統使這個自動完成(甚至不需要為應用服務添加 [UnitOfWork] 屬性)，
正確: 授權應該在應用層完成，這里，它是通過使用 [Authorize] 屬性來完成的
正確: 呼叫支付(基礎設施服務)來為該操作收費(創建組織在我們的業務中是一種付費服務)
正確: 應用服務方法負責將更改保存到資料庫，
正確: 我們可以發送電子郵件通知系統管理員
錯誤: 不要從應用程式服務回傳物體，而是回傳一個DTO，

討論:為什么我們不將支付邏輯轉移到領域服務中?

您可能想知道為什么支付代碼不在 OrganizationManager 中，這是一件很重要的事情，我們不想錯過付款，

然而，僅僅重要還不足以將代碼視為核心業務邏輯， 我們可能還有其他的用例，在這些用例中創建一個新的 Organization 是不需要收費的，比如:

管理員用戶可以使用后臺應用程式創建新的組織，而無需支付任何費用
后臺作業的資料匯入/集成/同步系統也可能需要創建沒有任何支付操作的組織，

如您所見，支付不是創建有效組織的必要操作，它是特定于用例的應用程式邏輯，

示例: 增刪改查操作

public class IssueAppService
{
    private readonly IssueManager _issueManager;
    public IssueAppService(IssueManager issueManager)
    {
        _issueManager = issueManager;
    }

    public async Task<IssueDto> GetAsync(Guid id)
    {
        return _issueManager.GetAsync(id);
    }

    public async Task CreateAsync(IssueCreationDto input)
    {
        return _issueManager.CreateAsync(input);
    }

    public async Task UpdateAsync(UpdateIssueDto input)
    {
        return _issueManager.UpdateAsync(input);
    }

    public async Task DeleteAsync(Guid id)
    {
        return _issueManager.DeleteAsync(id);
    }
}

這個應用程式服務本身不做任何事情，而是將所有作業委托給領域服務，它甚至將 dto 傳遞給 IssueManager

不要僅僅為沒有任何領域邏輯的簡單CRUD操作創建領域服務，
永遠不要向領域服務傳遞dto或從領域服務回傳dto，

應用程式服務可以直接使用存盤庫來查詢、創建、更新或洗掉資料，除非在這些操作期間需要執行一些領域邏輯，在這種情況下，創建 Domain Service 方法，但只針對那些真正需要的方法

如果你對領域驅動設計和構建大型企業系統更感興趣，推薦以下書籍作為參考書:

"Domain Driven Design" by Eric Evans
"Implementing Domain Driven Design" by Vaughn
Vernon
"Clean Architecture" by Robert C. Martin

完結

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/495593.html

標籤：.NET Core

上一篇：實作領域驅動設計 - 使用ABP框架 - 創建物體

下一篇：.Net Core 中使用工廠模式

實作領域驅動設計 - 使用ABP框架 - 領域邏輯 & 應用邏輯