基于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);
}
}
应用服务并没有做任何事情,而是委托给领域服务来处理。只接收DTO参数,并传递给 IssueManger
。
- 不要创建只实现简单 CRUD 操作的领域服务方法,而不带任何领域逻辑。
- 不要传递 DTO 给领域服务,或领域服务方法返回 DTO。
应用服务可以直接使用仓储,实现查询、创建、更新或删除数据,除非执行这些操作时需要处理领域逻辑,这种情况下,创建领域服务方法,但只针对那些真正需要的方法。
不要因为将来可能会需要这些CRUD领域服务方法,就去提前创建这些方法! 当需要时再去创建,并重构现有的代码。由于抽象了应用层,重构领域层不会影响到UI层和其他客户端。
学习帮助
围绕DDD和ABP Framework两个核心技术,后面还会陆续发布核心构件实现、综合案例实现系列文章,敬请关注!
ABP Framework 研习社(QQ群:726299208)
专注 ABP Framework 学习及DDD实施经验分享;示例源码、电子书共享,欢迎加入!
基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑的更多相关文章
- 基于ABP落地领域驱动设计-00.目录和小结
<实现领域驱动设计> -- 基于 ABP Framework 实现领域驱动设计实用指南 翻译缘由 自 ABP vNext 1.0 开始学习和使用该框架,被其优雅的设计和实现吸引,适逢 AB ...
- 基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则
目录 系列文章 领域服务 应用服务 学习帮助 系列文章 基于ABP落地领域驱动设计-00.目录和前言 基于ABP落地领域驱动设计-01.全景图 基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践 ...
- 基于ABP落地领域驱动设计-05.实体创建和更新最佳实践
目录 系列文章 数据传输对象 输入DTO最佳实践 不要在输入DTO中定义不使用的属性 不要重用输入DTO 输入DTO中验证逻辑 输出DTO最佳实践 对象映射 学习帮助 系列文章 基于ABP落地领域驱动 ...
- (转)EntityFramework之领域驱动设计实践
EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领 ...
- .net core +codefirst(.net core 基础入门,适合这方面的小白阅读) 【我们一起写框架】领域驱动设计的CodeFirst框架(一)—序篇
.net core +codefirst(.net core 基础入门,适合这方面的小白阅读) 前言 .net core mvc和 .net mvc开发很相似,比如 视图-模型-控制器结构.所以. ...
- EntityFramework之领域驱动设计实践
EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践 (一):从DataTable到EntityObject EntityFramework之领 ...
- 如何领域驱动设计?-实践感悟&总结分享
主要是在开发过程中,个人对于领域驱动设计的实践感悟和总结:也是对新进开发人员的培训资料:希望对关注DDD的童鞋有所帮助. 概述 领域驱动不是纯粹的技术问题,领域建模(建立数据表只是一部分)是领域专家( ...
- DDD 领域驱动设计-如何完善 Domain Model(领域模型)?
上一篇:<DDD 领域驱动设计-如何 DDD?> 开源地址:https://github.com/yuezhongxin/CNBlogs.Apply.Sample(代码已更新) 阅读目录: ...
- 领域驱动设计和实践(转:http://kb.cnblogs.com/page/112298/)
引言 软件系统面向对象的设计思想可谓历史悠久,20世纪70年代的Smalltalk可以说是面向对象语言的经典,直到今天我们依然将这门语言视为面向对象语言的基础.随着编程语言和技术的发展,各种语言特性层 ...
随机推荐
- 【技术博客】基于vue的前端快速开发(工具篇)
一.Vue教程 vue.js是一套构建用户界面的渐进式框架.vue采用自底向上增量开发的设计.vue的核心库只关心视图层,非常容易学习,非常容易与其它库和已有项目整合.vue完全有能力驱动采用单文件组 ...
- GPUImage移植总结
项目github地址: aoce 我是去年年底才知道有GPUImage这个项目,以前也一直没有在移动平台开发过,但是我在win平台有编写一个类似的项目oeip(不要关注了,所有功能都移植或快移植到ao ...
- Python编写abaqus后处理脚本(学习笔记)
本节内容参考自书籍<Python语言在Abaqus中的应用>,注意:以下代码为伪代码,仅供参考 1.导入必要的模块,加载后处理odb文件 from abaqus import * from ...
- 狄克斯特拉(Dijkstra)算法
引入 从A点到B点的最短路径是什么?求最短路径的两种算法:Dijkstra算法和Floyd算法. 网图:带权图. 非网图最短路径:两顶点间经过的边数最少的路径.(非网图也可被理解为各边权值为1的网图. ...
- 5分钟让你理解K8S必备架构概念,以及网络模型(下)
写在前面 在这用XMind画了一张导图记录Redis的学习笔记和一些面试解析(源文件对部分节点有详细备注和参考资料,欢迎关注我的公众号:阿风的架构笔记 后台发送[导图]拿下载链接, 已经完善更新): ...
- [bug] ERROR: Can't get master address from ZooKeeper; znode data == null
排错 访问bigdata111:50070没显示 jps发现hdfs的namenode没启动 查看namenode日志发现9000端口被占用 查找占用端口的进程 杀死进程,或在配置文件中更改端口号 参 ...
- Debian 9.4 多网卡链路聚合bond配置
Debian 9.4 多网卡链路聚合bond配置 安装ifenslave ifenslave 的作用是网卡的负载均衡 root@debian:~# apt-get install ifenslave ...
- Spark 集群安装部署
安装准备 Spark 集群和 Hadoop 类似,也是采用主从架构,Spark 中的主服务器进程就叫 Master(standalone 模式),从服务器进程叫 Worker Spark 集群规划如下 ...
- stm32之ADC应用实例(单通道、多通道、基于DMA)-转载精华帖,最后一部分的代码是精华
硬件:STM32F103VCT6 开发工具:Keil uVision4 下载调试工具:ARM仿真器网上资料很多,这里做一个详细的整合.(也不是很详细,但很通俗).所用的芯片内嵌3个12位的 ...
- gpgj - 06.估值分析举例
06.估值分析举例 1.举个栗子-贵州茅台的护城河 品牌效益高 只有高档产品 不卖中低档,不会拉低公司收入 { "question": "我们来复习一下护城河要如何分 ...