本文次要介绍了多应用层的问题，包含起因和实现。通过了解介绍了如何辨别畛域逻辑和应用逻辑，哪些是正确的实际，哪些是不举荐的或者谬误的实际。
一.多应用层的问题
1.多应用层介绍
不晓得你们是否会遇到一种状况，通过ABP构建了一个后端的API我的项目，刚开始是为Web端我的项目(比方，Vue)提供后端接口服务的，随着我的项目的倒退和业务的简单，减少了挪动端的App，或者公众号、小程序等，这样不仅要为Web端提供API服务，而且还须要为挪动端的App，或者公众号、小程序等提供API服务。这个场景就是多应用层的问题。也就是说你当初须要构建一个有多个应用程序的零碎了：
- Web应用程序：比方应用的ASP.NET Core MVC技术，次要用来给用户展现产品，游客模式是能够查看产品的，并不需要登录和验证。
- 后端管理应用程序：比方前端是Vue，后端的ASP.NET Core API，次要用来对产品进行增删改等操作。
挪动应用程序：比方前端是uni-app，后端是ASP.NET Core API，通过REST接口和后端通信。
2.多应用层例子
因为业务的复杂性，每个利用零碎都有本人的不同应用服务办法，不同的输出和输入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我的项目
二.如何辨别畛域逻辑和应用逻辑
通常，DDD中的业务逻辑包含畛域逻辑和应用逻辑。畛域逻辑由零碎的外围畛域规定组成，而利用程序逻辑实现特定于应用程序的用例。话虽这样说，然而并不容易辨别什么是畛域逻辑和应用逻辑。
1.在畛域服务层中创立组织Organization
上面通过在畛域服务中创立Organization这个例子，来尽可能简要阐明：
public class OrganizationManager:DomainService{ private readonly IRepository<Organization> _organizationRepository; //Organization的仓储 private readonly ICurrentUser _currentUser; //以后用户 private readonly IAuthorizationService _authorizationService; //Authorization的服务 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; }}- 畛域服务不做权限验证，权限验证放在应用层来做
- 用户概念是应用层或展现层的相干概念，记录日志不应该蕴含以后用户的用户名
- 创立一个新的组织，并发送邮件，这个业务逻辑也应该放在应用层
2.在应用层中应用畛域服务创立组织Organization
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... }}应用服务层的输出和输入参数都是DTO，不能返回实体。至于为什么不将领取放在畛域服务中，只能说业务重要也不肯定放在畛域服务中，具体起因阐明参考[1]。
参考文献：
[1]基于ABP Framework实现畛域驱动设计：https://url39.ctfile.com/f/25... (拜访明码: 2096)
本文由mdnice多平台公布