关于jimmer的dto描述文件该放在哪里讨论（接口包、服务实现包分离的情况）

[tzxylao]

jimmer我发现一个问题，他的dto描述文件是通过接口类聚合根生成对应的比如输入条件类xxxInput.class，这个类是要用在接口的，也就是说一定要暴露出去，是这样吧？现在我的服务分为两个包：一个接口包需要被别的服务引用，一个service包写具体实现。那我的dto描述文件该写在哪里？服务层明显是依赖接口包的，我如果写在服务层，生成的代码类就在服务层了，接口层引用不到不就暴露不出去了？如果写在接口层，接口层不依赖服务层，jimmer的接口聚合根类难道要写在接口层？聚合根是操作数据库的不应该暴露出去吧？这就悖论了，jimmer有考虑这种情况吗？如何解决

[babyfish-ct]

写在业务接口层，声明业务API要用。官方例子中，DTO文件定义在serevice项目中。

数据层用抽象写法 (数据结构形状未知，尽可能万能，无需使用DTO编译生成的类型)

interface BookRepository {
   <V extends View<Book>> List<V> findBooksBy???();
   saveBook(Input<Book> input);
}

业务层用具体写法 (数据结构形状确定，尽可能固化，这就需要使用DTO编译生成的类型)

interface XxxService {
    List<BookXxxView> findBooksBy???();
    saveBook(BookXxxInput input);
}
interface YyyService {
    List<BookYyyView> findBookBy???();
    saveBook(BookYyyInput input);
}

DTO依赖的接口View, Input, Specication，都定义在org.babyfish.jimmer下，而非org.babyfish.jimmer.sql下。

[tzxylao]

目前遇到的问题是不是服务层和数据层的关系问题，是对外暴露的接口层和服务实现层的依赖问题，我的服务是服务层依赖接口层的，所以自动生成的文件要能被接口层和服务层都用到必须放接口层。
这个dto文件放在对外暴露的接口层的话，比如这样
export com.xxx.space.aggregate.SpaceUserRoot
-> package com.xxx.space.interfaces.service.dto
我的数据库Entity是 com.xxx.space.aggregate.SpaceUserRoot 这个应该在服务层的，但想要dto生成的Input之类的文件（com.xxx.space.interfaces.service.dto）应该在接口层，这横跨两个服务包了，目前能实现吗？ @babyfish-ct

[babyfish-ct]

放到接口层，传染到Service层，不行？

[tzxylao]

问题是数据库Entity(也就是例子的Book类)的定义是不是也要放在接口层了？本来数据库实体的定义不都在服务实现层的repository下，这样子必须把这全部的定义都放接口层了。没别的办法了吗？ @babyfish-ct

[babyfish-ct]

实体应该放到独立项目，跨越所有层。DTO定义在接口项目，但接口项目以来实体项目

JimmerDTO和手写DTO不同，目的就是

1，完成Entity的转移
2. 附带数据库操作，比如fetcehr， qbe
3. 2中的操作要通过Input, View, Specification等接口供框架访问

所以，可以认为几乎没有可能。

[babyfish-ct]

微服务项目想Feign吗？

[babyfish-ct]

临时解决方案：定义接口，让DTO实现接口

1. 如果如果微服务需要Feign，日后jimmer-client会提供Java/Kotlin版本的代码生成，不依赖Feign/Spring那套，绝对技术中立。目前没时间不够，优先级后移

2. 如果是DDD那套接口是实现分离，DDD的初衷是为了把数据访问技术剥离出去可，留下业务逻辑。但以Jimmer功能的强大，不可能找到能不修改编程模型直接平替的东西。设计前就是怎么考虑的，打造一个全新的便捷的难以平替的新编程模型，就不会有人去想平替的事了。

3. 如果必须实施DDD，且前文讲述的定义接口让DTO实现是也接受，那就不用Jimmer DTO，自定定义DTO.