基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

系列文章
领域逻辑和应用逻辑
- 多应用层
- 示例：正确区分应用逻辑和领域逻辑
学习帮助

系列文章

基于ABP落地领域驱动设计-00.目录和前言
基于ABP落地领域驱动设计-01.全景图
基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践和原则
基于ABP落地领域驱动设计-03.仓储和规约最佳实践和原则
基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则
基于ABP落地领域驱动设计-05.实体创建和更新最佳实践
基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑

围绕DDD和ABP Framework两个核心技术，后面还会陆续发布核心构件实现、综合案例实现系列文章，敬请关注！

ABP Framework 研习社（QQ群：726299208）

ABP Framework 学习及实施DDD经验分享；示例源码、电子书共享，欢迎加入！

领域逻辑和应用逻辑

正如前面提到的，领域驱动设计中的业务逻辑拆分为两部分：领域逻辑和应用逻辑。

领域逻辑由系统的核心领域规则组成，而应用程序逻辑实现特定于应用程序的用例。

虽然定义很清楚，但实现可能并不容易，常常无法决定哪些代码应该放在应用层，哪些代码应该放在领域层。本节试图解释这些差异。

多应用层

当你的系统很大时，DDD有助于处理复杂性问题。特别是，在一个领域中开发多个应用，那么领域逻辑与应用逻辑的分离就变得更加重要。

假设你正在构建一个有多个应用程序的系统：

一个Web应用程序，使用 ASP .NET Core MVC，展示产品给用户。浏览产品，不需要进行身份验证；只有当用户执行某些操作时，比如向购物车中添加产品，才会要求登陆。
一个后台管理应用程序，使用Angular UI+ REST APIs构建。此应用由公司办公人员做系统管理，比如：编辑产品描述。
一个移动应用程序，和 Web应用程序相比UI更加简单，通过REST APIs或其他技术（如：TCP/Socket）与服务器通信。

每一个应用都需要解决不同的需求，实现不同用例（应用服务方法），不同DTO，不同验证和授权规则等等。

将所有这些逻辑混合到一个应用层中，将使你的服务包含太多的判断条件和复杂的业务逻辑，使代码更难开发、维护和测试，并导致潜在的Bug。

如果你有单个领域关联多个应用程序：

为每个应用程序或客户端创建单独的应用层，在这些单独层中实现特定于应用的业务逻辑。
使用单个领域层共享核心领域逻辑。

这样的设计使得区分领域逻辑和应用逻辑变得更加重要。

为了更清楚地实现，可以为每种应用程序类型创建不同的项目(.csproj)。

例如：

后台管理应用创建 IssueTracker.Admin.Application 和 IssueTracker.Admin.Application.Contracts 项目
WEB应用创建 IssueTracker.Public.Application 和 IssueTracker.Public.Application.Contracts
移动应用创建 IssueTracker.Mobile.Application 和 IssueTracker.Mobile.Application.Contracts

示例：正确区分应用逻辑和领域逻辑

本节包含一些应用服务和领域服务示例，讨论如何决定在这些服务中放置业务逻辑。

示例：在领域服务中创建 Organization （组织）

public class OrganizationManager:DomainService { private readonly IRepository<Organization> _organizationRepository; private readonly ICurrentUser _currentUser; private readonly IAuthorizationService _authorizationService; private readonly IEmailSender _emailSender; public OrganizationManager( IRepository<Organization> organizationRepository, ICurrentUser currentUser, IAuthorizationService authorizationService, IEmailSender emailSender ) { _organizationRepository=organizationRepository; _currentUser=currentUser; _authorizationService=authorizationService; _emailSender=emailSender; } //创建组织 public async Task<Organization> CreateAsync(string name) { //检测是否存在同名组织，存在则抛出异常。 if(await _organizationRepository.AnyAsync(x=>x.Name==name)) { throw new BusinessException("IssueTracking:DuplicateOrganizationName"); } //检测是否拥有创建权限 await _authorizationService.CheckAsync("OrganizationCreationPermission"); //记录日志 Logger.LogDebug($"Creating organization {name} by {_currentUser.UserName}"); //创建组织实例 var organization = new Organization(); //发送提醒邮件 await _emailSender.SendAsync( "systemadmin@issuetracking.com", "新组织", "新组织名称："+name ); //返回组织实例 return organization; } }

让我们一步一步来分析 CreateAsync 方法中的代码是否都应该放在领域服务中：

正确：组织名重复检测，存在重复名称则抛出异常。该检测与核心领域规则相关，不允许重名。
错误：领域服务不应该进行权限验证。权限验证应该放在应用层。
错误：记录日志包含当前用户的用户名。领域服务不应该依赖当前用户，当前用户（Session）应该是展示层或应用层中的相关概念。
错误：创建新组织发送邮件，我们仍然认为这是业务逻辑。可以能会根据用例来创建不同类型邮件。

示例：在应用层创建新组织

public class OrganizationAppService:ApplicationService { private readonly OrganizationManager _organizationManager; private readonly IPaymentService _paymentService; private readonly IEmailSender _emailSender; public OrganizaitonAppService( OrganizationManager organizationManager, IPaymentService paymentService, IEmailSender emailSender ) { _organizationManager=organizationManager; _paymentService=paymentService; _emailSender=emailSender; } [UnitOfWork] [Authorize("OrganizationCreationPermission")] 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( "systemadmin@issuetracking.com", "新组织", "新组织名称："+name ); //返回实例 return organization; } private double GetOrganizationPrice() { return 42;//Gets form somewhere... } }

让我们看看 CreateAsync 方法，一步一步讨论其中的代码是否应该放在应用服务：

正确：应用服务方法应该是工作单元，ABP框架工作单元系统自动实现，可以不用添加[UnitOfWork]特性。
正确：权限验证应该放在应用层，可以使用 [Authorize] 特性。
正确：在我们的业务逻辑中创建组织是付费服务，当前操作调用基础设施服务进行支付操作。
正确：应用服务方法负责保存变更到数据库。
正确：给系统管理员发送邮件通知。
错误：不能返回实体，应该返回DTO。

讨论：为什么我们不应该将支付逻辑放在领域服务中？

你可能想知道为什么付款代码不在 OrganizationManager 里面。这是一件很重要的事情，我们绝不希望付款出错。

然而，业务的重要性并不意味着要将其视为核心业务逻辑。我们可能有其他的支付用例，在这些用例中，我们不收取费用来创建一个新的组织。

例如：

后台办公系统中的管理员用户可以创建新组织，不用考虑支付。
系统数据导入、整合、同步，也可能需要在没有任何支付操作的情况下，创建组织。

如您所见，支付不是创建一个有效组织的必要操作。它是一个特定于用例的应用逻辑。

示例：CRUD操作

public class IssueAppService { private readonly IssueManager _issueManager; public IssueAppService(IssueManager issueManager) { _issueManager=issueManager; } public async Task<IssueDto> GetAsync(Guid id) { return await _issueManager.GetAsync(id); } public async Task CreateAsync(IssueCreationDto input) { await _issueManager.CreateAsync(input); } public async Task UpdateAsync(UpdateIssueDto input) { await _issueManager.UpdateAsync(input); } public async Task DeleteAsync(Guid id) { await _issueManager.DeleteAsync(id); } }