本文是DDD框架实现讲解的第二篇,主要介绍了DDD的Application层的实现,详细讲解了service、assemble的职责和实现。文末附有github地址。相比于《领域驱动设计》原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解。本文是【DDD】系列文章的其中一篇,其他可参考:使用领域驱动设计思想实现业务系统

Application层

  在DDD设计思想中,Application层主要职责为组装domain层各个组件及基础设施层的公共组件,完成具体的业务服务。Application层可以理解为粘合各个组件的胶水,使得零散的组件组合在一起提供完整的业务服务。在复杂的业务场景下,一个业务case通常需要多个domain实体参与进来,所以Application的粘合效用正好有了用武之地。

  Application层主要由:service、assembler组成,下面分别对其做讲解。

Service

service是组件粘合剂

  这里的Service区别于domain层的domain service,是应用服务。它是组件的粘合剂,组合domain层的各个组件和 infrastructure层的持久化组件、消息组件等等,完成具体的业务逻辑,提供完整的业务服务。

  通过不断的实践,我们发现:通过DDD实现业务服务时,检验业务模型的质量的一个标准便是 —— service方法中不要有if/else。如果存在if/else,要么就是系统用例存在耦合,要么就是业务模型不够友好,导致部分业务逻辑泄漏到service了。

  通常意义上,一个业务case在service层便会对应一个service方法,这样确保case实现的独立性。拿社区服务中的“帖子”模块来讲,我们有如下几个明显的case:发帖(posting)、删帖(deletePost)、查询帖子详情(queryPostDetail),这些case在service层都对应独立的业务方法。

思考

  对于较为复杂的case:查询帖子列表,可能需要根据不同的tag过滤帖子,或者查询不同类型的帖子,或者查询热门帖子,这个时候应当用一个service方法实现呢?还是多个呢?

  考虑这个问题,主要从这两方面入手:domain的一致性,数据存储的一致性;如果两个一致性都满足,那么我们可以在一个业务方法中完成,否则就要在独立的业务方法中完成。

  例如:根据帖子运营标签查询帖子 和 查询全部帖子列表 这两个case我们可以放到一个service方法中实现,因为前一个case只是在后一个case的基础上加了一个过滤条件,这个过滤条件完全可以交给dao层的sql where条件处理掉,除此之外,domain和repository都完全一样;

  而“查询热门帖子” 这个case就不能和上面的两个case共用一个service方法了,因为热门帖子列表的数据源并不在数据库中,而是存在于缓存中,因此repository的取数逻辑存在很大差异,如果共用一个service方法,势必要在service层出现if/else判定,这是不友好的。

类图

代码示例

 @Service
public class PostServiceImpl implements PostService { @Autowired
private IPostRepository postRepository; @Autowired
private PostAssembler postAssembler; public PostingRespBody posting(RequestDto<PostingReqBody> requestDto) throws BusinessException {
PostingReqBody postingReqBody = requestDto.getBody();
/**
*NOTE: 请求参数校验交给了validation,这里无需校验userId和postId是否为空
*/
String userId = postingReqBody.getUserId();
String title = postingReqBody.getTitle();
String sourceContent = postingReqBody.getSourceContent(); long userIdInLong = Long.valueOf(userId); /**
* 组装domain model entity
* NOTE:这里的PostAuthor不需要从repository重载,原因在于:deletePost场景需要用户登录后才能操作,
* 在进入service之前,已经在controller层完成了用户身份鉴权,故到达这里的userId肯定是合法的用户
*/
PostAuthor postAuthor = new PostAuthor(userIdInLong);
Post post = postAuthor.posting(title, sourceContent); /**
* NOTE:使用repository将model entity 写入存储
*/
postRepository.save(post); /**
* NOTE:使用postAssembler将Post model组装成dto返回。
*/
return postAssembler.assemblePostingRespBody(post);
} public DeletePostRespBody delete(RequestDto<DeletePostReqBody> requestDto) throws BusinessException {
DeletePostReqBody deletePostReqBody = requestDto.getBody(); /**
*NOTE: 请求参数校验交给了validation,这里无需校验userId和postId是否为空
*/
String userId = deletePostReqBody.getUserId();
String postId = deletePostReqBody.getPostId(); long userIdInLong = Long.valueOf(userId);
long postIdInLong = Long.valueOf(postId); /**
* 组装domain model entity
* NOTE:这里的PostAuthor不需要从repository重载,原因在于:deletePost场景需要用户登录后才能操作,
* 在进入service之前,已经在controller层完成了用户身份鉴权,故到达这里的userId肯定是合法的用户
*/
PostAuthor postAuthor = new PostAuthor(userIdInLong);
/**
* 从repository中重载domain model entity
* 借此判断该postId是否真的存在帖子
*/
Post post = postRepository.query(postIdInLong); postAuthor.deletePost(post); postRepository.delete(post); return null;
} @Override
public QueryPostDetailRespBody queryPostDetail(RequestDto<QueryPostDetailReqBody> requestDto)
throws BusinessException {
QueryPostDetailReqBody queryPostDetailReqBody = requestDto.getBody(); String readerId = queryPostDetailReqBody.getReaderId();
String postId = queryPostDetailReqBody.getPostId(); long readerIdInLong = Long.valueOf(readerId);
long postIdInLong = Long.valueOf(postId); //TODO 可能有一些权限校验,比如:判定该读者是否有查看作者帖子的权限等。这里暂且不展开讨论。
PostReader postReader = new PostReader(readerIdInLong); Post post = postRepository.query(postIdInLong); /**
* NOTE: 使用postAssembler将domain层的model组装成dto,组装过程:
* 1、完成类型转换、数据格式化;
* 2、将多个model组合成一个dto,一并返回。
*/
return postAssembler.assembleQueryPostDetailRespBody(post);
} }

Assembler

Assembler是组装器

  Assembler是组装器,负责完成domain model对象到dto的转换,组装职责包括:

  1. 完成类型转换、数据格式化;如日志格式化,状态enum装换为前端认识的string;
  2. 将多个domain领域对象组装为需要的dto对象,比如查询帖子列表,需要从Post(帖子)领域对象中获取帖子的详情,还需要从User(用户)领域对象中获取用户的社交信息(昵称、简介、头像等);
  3. 将domain领域对象属性裁剪并组装为dto;某些场景下,可能并不需要所有domain领域对象的属性,比如User领域对象的password属性属于隐私相关属性,在“查询用户信息”case中不需要返回,需要裁剪掉。

示例代码  

 /**
* Post模块的组装器,完成domain model对象到dto的转换,组装职责包括:
* 1、完成类型转换、数据格式化;如日志格式化,状态enum装换为前端认识的string;
* 2、将多个model组合成一个dto,一并返回。
* TODO: 不太好的地方每个assemble方法都需要先判断入参对象是否为空。
* @author daoqidelv
* @createdate 2017年9月24日
*/
@Component
public class PostAssembler { private final static String POSTING_TIME_STRING_DATE_FORMAT = "yyyy-MM-dd hh:mm:ss"; @Autowired
private ApplicationUtil applicationUtil; public PostingRespBody assemblePostingRespBody(Post post) {
if(post == null) {
return null;
}
PostingRespBody postingRespBody = new PostingRespBody();
postingRespBody.setPostId(String.valueOf(post.getId()));
return postingRespBody;
} public QueryPostDetailRespBody assembleQueryPostDetailRespBody(Post post) {
/**
* NOTE: 判定入参post是否为null
*/
if(post == null) {
return null;
}
QueryPostDetailRespBody queryPostDetailRespBody = new QueryPostDetailRespBody();
queryPostDetailRespBody.setAuthorId(String.valueOf(post.getAuthorId())); //完成类型转换
queryPostDetailRespBody.setPostId(String.valueOf(post.getId()));//完成类型转换
queryPostDetailRespBody.setPostingTime(
applicationUtil.convertTimestampToString(post.getPostingTime(), POSTING_TIME_STRING_DATE_FORMAT));//完成日期格式化
queryPostDetailRespBody.setSourceContent(post.getSourceContent());
queryPostDetailRespBody.setTitle(post.getTitle());
return queryPostDetailRespBody;
} }

思考

  上述代码实现中,每一个assemble方法都需要校验入参对象是否为空,实践中发现,这一个关键点很容易遗漏,没有想到好的办法解决。

类图

demo

  此demo的代码已上传至github,欢迎下载和讨论,但拒绝被用于任何商业用途。

  github地址:https://github.com/daoqidelv/community-ddd-demo/tree/master

  branch:master

【DDD】领域驱动设计实践 —— Application层实现的更多相关文章

  1. 【DDD】领域驱动设计实践 —— UI层实现

    前面几篇blog主要介绍了DDD落地架构及业务建模战术,后续几篇blog会在此基础上,讲解具体的架构实现,通过完整代码demo的形式,更好地将DDD的落地方案呈现出来.本文是架构实现讲解的第一篇,主要 ...

  2. DDD领域驱动设计之运用层代码

    1.DDD领域驱动设计实践篇之如何提取模型 2.DDD领域驱动设计之聚合.实体.值对象 3.DDD领域驱动设计之领域基础设施层 4.DDD领域驱动设计之领域服务 5.整体DEMO代码 什么是运用层,说 ...

  3. 【DDD】领域驱动设计实践 —— Domain层实现

    本文是DDD框架实现讲解的第三篇,主要介绍了DDD的Domain层的实现,详细讲解了entity.value object.domain event.domain service的职责,以及如何识别出 ...

  4. DDD领域驱动设计和实践(转载)

    -->目录导航 一. DDD领域驱动设计介绍 1. 什么是领域驱动设计(DDD) 2. 领域驱动设计的特点 3. 如果不使用DDD? 4. 领域驱动设计的分层架构和构成要素 5. 事务脚本和领域 ...

  5. DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践(2)

    上一篇:<DDD 领域驱动设计-谈谈 Repository.IUnitOfWork 和 IDbContext 的实践(1)> 阅读目录: 抽离 IRepository 并改造 Reposi ...

  6. DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践(1)

    好久没写 DDD 领域驱动设计相关的文章了,嘎嘎!!! 这几天在开发一个新的项目,虽然不是基于领域驱动设计的,但我想把 DDD 架构设计的一些东西运用在上面,但发现了很多问题,这些在之前的短消息项目中 ...

  7. DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践(转)

    http://www.cnblogs.com/xishuai/p/ddd-repository-iunitofwork-and-idbcontext.html 好久没写 DDD 领域驱动设计相关的文章 ...

  8. DDD领域驱动设计落地实践(十分钟看完,半小时落地)

    一.引子 不知今年吹了什么风,忽然DDD领域驱动设计进入大家视野.该思想源于2003年 Eric Evans编写的"Domain-Driven Design领域驱动设计"简称DDD ...

  9. DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践(3)

    上一篇:<DDD 领域驱动设计-谈谈 Repository.IUnitOfWork 和 IDbContext 的实践(2)> 这篇文章主要是对 DDD.Sample 框架增加 Transa ...

随机推荐

  1. 读书笔记--C陷阱与缺陷(二)

    第二章 1. 理解函数声明 书中分析了复杂的类型声明方式,也说明了使用typedef声明会更好理解,推荐大家使用typedef进行函数声明. 书中类型分析一层一层挖掘,让读者可以理解多层嵌套的类型含义 ...

  2. HTTP协议的8种请求类型介绍

    HTTP协议的8种请求类型介绍 转自:http://www.cnblogs.com/liangxiaofeng/p/5798607.html HTTP协议的8种请求类型介绍 HTTP协议中共定义了八种 ...

  3. 一文教你迅速解决分布式事务 XA 一致性问题

    欢迎大家前往腾讯云技术社区,获取更多腾讯海量技术实践干货哦~ 作者:腾讯云数据库团队 近日,腾讯云发布了分布式数据库解决方案(DCDB),其最明显的特性之一就是提供了高于开源分布式事务XA的性能.大型 ...

  4. [2012-05-31]awk去重复项

    参考http://bbs.chinaunix.net/thread-2309494-1-1.html 10.awk '! a[$0]++' 怎么理解? 这是一个非常经典的去重复项的awk语句,虽然短小 ...

  5. Hash表分析

    http://baike.baidu.com/link?url=Ua74895uGf1NuPxB4pawmuAXedi427jJvM6aSLh_V1-23ptlMc7XIrr_cylIBn5d

  6. Topshelf便捷创建Windows服务

    结合Quartz.net学习,前提已经创建了一个定时任务,可见 <定时调度框架:Quartz.net> (基于配置文件形式) 首先引用Topshelf.dll 自定义服务TestServi ...

  7. mqtt实现自动监听服务器消息

    本示例借助meteor的一个环境跑,和我们平时用的node自己搭的环境或java,php的环境本质一样,在此不多讨论. 首先需求是:多系统对接进行消息实时传递. 安装好mqtt:  npm insta ...

  8. OSX 10.8+下开启Web 共享 的方法

    MENU Home Archives About SUBSCRIBE ☰MENU OSX 10.8+ Mountain Lion 下开启 Web Sharing(Web 共享)的方法 JUL 28, ...

  9. CCIE-MPLS VPN-实验手册(上卷)

    看完了看完了看完了,豪爽豪爽豪爽,一个月了,写得挺棒.总共14个mpls vpn的实验,为留下学习的痕迹,原封不动献出. CCIE实验手册 (路由部分-MPLSVPN基础篇) [CCIE]  JUST ...

  10. 【Beta】 第五次Daily Scrum Meeting

    一.本次会议为第五次meeting会议 二.时间:10:00AM-10:20AM 地点:陆大楼 三.会议站立式照片 四.今日任务安排 成员 昨日任务 今日任务 林晓芳 帮助完善登录界面 对目前完成的模 ...