ouchuangxin / leave-sample Goto Github PK

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

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

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

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

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

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

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

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

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

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

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

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

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;
}

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

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