ouchuangxin/leave-sample

本代码来源于极客时间《DDD实战》专栏。

leave-sample

一、说明

本代码源于极客时间《DDD实战课》，DDD知识体系和代码详解可参考专栏。

在《DDD实战课》专栏第18节中我们用事件风暴完成了“在线请假考勤”项目的领域建模和微服务设计。 我们一起从程序员的视角去看看用DDD方法设计和开发出来的微服务代码到底是什么样的？

二、项目回顾

“在线请假考勤”项目中，请假的核心业务流程是：“请假人填写请假单提交审批。根据请假人身份、请假类型和请假天数进行校验并确定审批规则。根据审批规则确定审批人，逐级提交上级审批，逐级核批通过则完成审批，否则审批不通过则退回申请人。”

在第18节的DDD领域建模和微服务设计中，我们已经拆分出了两个微服务：请假和考勤微服务。 本部分是请假微服务的示例代码，采用的开发语言和数据库分别是：Java、Spring boot和PostgreSQL。

三、请假微服务采用的DDD设计**

请假微服务中用到了很多DDD设计**和方法，主要包括以下几点。

1.聚合的管理：聚合根、实体和值对象的关系。

2.聚合数据的初始化和持久化：工厂和仓储模式。

3.聚合的解耦：聚合代码的解耦、跨聚合的服务调用和对象解耦。

4.领域事件管理：领域事件实体结构、持久化和事件发布。

5.DDD分层架构：基础层、领域层、应用层和用户接口层的协作。

6.服务的分层与协作：实体方法、领域服务、应用服务、接口服务，服务的组合和编排，跨多个聚合的服务管理和协同。

7.对象的分层和转换：DTO、DO和PO等对象在不同层的转换和实现过程。

8.微服务之间的访问：登录和认证服务。

leave-sample's Issues

interfaces里面内容是按domain还是功能来分？

interfaces层里面的内容，示例代码中是按照功能来分的，比如controller都放在facade目录中，dto都放在dto目录中。这里为什么没有按照domain来分呢？比如：

interfaces
|----leave
| |----dto
| |----facade
|----user
| |----dto
| |----facade

垃圾的不行，编译都通不过

好多报错啊

感觉是个半成品，好多都跑不通

分层

数据库访问为啥要放在domain层里面?

不得不说，课程扯了一大堆有的没的，落地到代码就原形毕露了。极其水的一门课

-代码编译都不通过也好意思往master上push.
-比起传统的三层架构，除了多了个在service和dao层之间再加了个repository层，另外搞了些花里胡哨的包名。请问还有啥？
-真是talk is cheap, show me the code.

感觉作者对DomainService有误解

我的理解，DomainService一般是用来实现业务逻辑的，协调跨聚合的业务逻辑。
但作者在这里，把DomainService当成ApplicationService。比如，LeaveDomainService.submitApproval方法，基本与业务逻辑无关，还引用@transactional,Repository，使得Domain项目引用了技术相关的概念。

您好，有个问题想跟您探讨一下

1.我看到仅仓储层出现了接口定义，在其它层是不是最好不要使用接口定义了？
2.感觉跟之前的事务基本的架构分层模式的区别主要是：最外层分包结构叫法不太一样但跟之前的controller,service,dao没有太大区别、实体类中多了一些业务逻辑方法、多了事件处理；
3.感觉DDD最主要还是对边界的严格控制上，具体怎么分包并无太大区别。

请问表结构在哪

没想到水军这么多

• 个人感觉这个示例代码已经是比较不错的
• 我猜 上来就喷的 要么就是其他机构的水军 要么就是真的不懂？
• 你行你po一个示例代码的库也给我们瞅瞅？

代码和文章水平不在一个层次吧！！！😂

看文章，写的头头是道的，结果代码拉下来，一言难尽，很难让人觉得这是同一个人的产出。
注释，包装类型，代码括号。既然，是一个教程我觉得还是写的规范一点好，我这拉下来P3C检测，夸夸的提示。

有些代码实现和设计对应不上

领域层不应该直接依赖基础层，应该在domain定义eventPublisher的接口，基础层实现，两者依赖共同的抽象。
另外建议项目创建为多module的格式，强制规定好依赖关系。

代码编译报错

PersonAssembler.toDO()的ParseException未处理

public Response login(PersonDTO personDTO) throws ParseException {
    return loginApplicationService.login(PersonAssembler.toDO(personDTO));
}

public static Person toDO(PersonDTO dto) throws ParseException {
    Person person = new Person();
    person.setPersonId(dto.getPersonId());
    person.setPersonType(PersonType.valueOf(dto.getPersonType()));
    person.setPersonName(dto.getPersonName());
    person.setStatus(PersonStatus.valueOf(dto.getStatus()));
    person.setCreateTime(DateUtil.parseDateTime(dto.getCreateTime()));
    person.setLastModifyTime(DateUtil.parseDateTime(dto.getLastModifyTime()));
    return person;
}

疑问：每次查询都要把整个Do实例化出来，有时候我们只需要一个属性而已，性能问题怎么解决

说一套做一套的感觉

请问，分页查询这类对象应该放在哪层？

作为DDD的初学者，想在项目中使用分层结构，对于单一字段的查询很好理解，但如果是一定条件的分页查询，需要把这个Bean放在哪个位置？

fork后重写了可运行，供参考

https://github.com/bobbyz007/leave-sample

auth里少个异常的import，能炸出这么多水军

总有人看到别人犯错就很开心

代码逻辑有误

这个地方 应该是 null != personPO 把