2019-11-29应用层其实我觉得入参数是DTO比较好，因为应用层是要暴漏给其他微服务调用的。然后在应用层将DTO转为DO来调用领域服务。如果调用其他微服务，则构造对方服务需要的DTO来调用。作者回复: 如果是你说的这种情况，也是可以的。
4
2019-11-20欧老师你好
用户接口层：入参是DTO，内部将DTO转化为DO后调用应用层，将应用层的结果转化为VO后返回给前台
应用层：入参是DO，返回值是DO
领域层：入参是DO，返回值是DO
基础层：入参是DO，内部将DO转化成PO进行数据库的增删改查，执行结果用PO去映射，再转化为DO作为基础层的返回值
问题1：时间范围查询时，会有辅助字段，如：beginTime和endTime，PO这怎么处理？我们的处理方式是增删改用PO，查询时候用QueryPO，QueryPO继承了PO并额外增加用于查询的辅助字段（比如时间、集合、模糊查询等），这样可以么？
问题2：有的查询功能，比如按照名称查询，查询条件就是name，DTO、DO和PO是一样的，也需要在每一层都去转化一下么？我们把查询时的对象命名为QueryPO，从用户接口层到基础层的入参都是这一个，这样可以么？展开作者回复: 1、可以的。
2、是否要做数据转换？主要是考虑解耦，这样各层不必受其它层的数据限制，它类似齿轮，通过数据转换来做适配。如果从前端到后端数据对象都是一样的，用一个对象其实也是可以的。要结合自己的场景来分析。 2 4
2019-11-20传入数据的格式校验放在哪层做？例如手机号格式校验、姓名长度校验等作者回复: 前端可以做简单格式校验，稍微复杂数据的校验在应用层。业务规则和逻辑校验在领域层。
你说的这两个前端就可以校验。 3 3
2019-12-25用户接口层会完成 DO 和 DTO 的互转，那不就等于将DO暴露给用户接口层了？按我的理解，DO从领域服务出来的时候就应该转换为DTO给应用层，从应用层开始往上（包括应用层）都不知道DO的存在；DO和DTO的互转，由领域服务负责，接收上层（应用层）传递的DTO，转换为DO，进而调用DO的方法完成业务逻辑，再将需要返回的数据转换为DTO返回给上层作者回复: DTO放应用层或者用户接口层都是可以的，保证外层依赖内层的原则就可以了，这些对象都在同一个微服务内。当应用服务调用其它微服务的应用服务的时候，DO和DTO的转换就在应用层。
1
2019-12-13领域实体是entity，领域对象是do，那Do就是entity么？
是的话，那po到do的转换一般是EF等框架自己做的了吧？作者回复: 是的，实体就是DO。
PO与DO的互转，Java大部分都需要自己写代码转换。
.net倒是有一些框架可以自动去做映射，比如你说的EF。 1
2019-11-20在数据试图这里，如果有用户User，那么在后端代码中是不是会有：
com.xxx.xxx.po.User
com.xxx.xxx.do.User
com.xxx.xxx.dto.User
或者为了方便区分则可以：
com.xxx.UserPO
com.xxx.User
com.xxx.UserDTO
？展开作者回复: 是的，但是有的时候不一定是一对一的关系。
1- 2019-11-20欧老师，微服务之后，前后端分离。前端和后端的登陆认证用什么来做呢？基于token的方式，“退出登录”是假的退出吧？是不是只在前端应用删除了保存的key，对于后端应用，这个key还是生效的
作者回复: 我们前端用JWT实现单点登录。后端微服务的服务调用通过API鉴权来控制。
1 1 
2019-11-20老师，微服务之间分布式事务，是有修改就用，还是应该根据具体业务做取舍？作者回复: 根据你的业务来取舍吧，如果数据不一致没关系，或者数据不重要，部分数据丢了也可以，就可以不用。
如果是核心业务数据或者涉及到钱的业务数据，分布式事务就必不可少了。 1
2019-11-20设计不同的对象，能够保证。当基于下层业务变化时。只需要更改，对象的转化即可。不需要对业务逻辑进行变更。对吗？作者回复: 是的。除非带来业务逻辑变化了，才去做变更。
1
2020-01-10老师你好，我想问下：
1、DO里面是充血模型是么？
2、如果要是充血模型，那对DO的最基础的增删改查都写在DO里面是么？作者回复: 除了增删改查，还有实体的业务行为，具体表现为实体的方法。
2020-01-07有这样一种情况：假设一个DTO对象是前端展示需要的，包含20个属性（假设是field1到field2）；后端有两个领域层的接口A和B。A需要更新这个DTO对象的field1到field5，B接口需要更新field3到field8。这种情况需要怎么处理比较好？针对A和B接口分别在内部定义一个对象作为参数，然后和DTO互相转换么？作者回复: A和B可以分别返回两个DO，然后将它们组装成你需要的前端展现的DTO就可以了。
2019-12-28曾经定义过这么多o，结果发现使用起来很不方便，感觉要把自己玩死😂 。最后还是觉得怎么用方便怎么定义，理论要结合实际。作者回复: 建立这么多O主要是为了解耦，如果系统不够复杂，业务和需求不会经常变动，可以根据自己的需要来定。其实用起来也还可以，你可以用工厂模式。
2019-12-19请问应用层需要访问repository层返回一些查询数据时，repository是只能返回DO，还是说也可以返回为DTO呢，谢谢。作者回复: repository返回的一般都是DO。
复杂查询可以采用CQRS读写分离的模式。 1
2019-12-13老师，“领域服务和应用服务都可以调用仓储服务接口，通过仓储服务实现数据持久化。” 聚合根里也可以调用仓储服务接口吧？作者回复: 是的，但是一般聚合根用的少，很多情况聚合根要作为对象传到基础层。
2019-12-11用户接口层对客户端提供接口访问，应用层提供服务之间的访问，建议dto统一在应用层进行检验；而且应用层的服务也需要注册成rpc或者restful的，同时访问路径与访问权限不一样作者回复: 都可以的，在应用层更统一。
2019-12-11应用层和服务层都有各自的po？对照着老师的结合自己的项目来做一遍发现有好多问题都不知道怎么下手啊作者回复: PO只在基础设施层。它与应用层和领域层的DO互转。
1
2019-12-09想问一下领域层，实体想要调用仓储接口的时候，参数接口的注入放在实体中吗，还是放在领域服务里面作者回复: 仓储接口可以被领域服务和应用服务调用，在仓储接口中传入实体ID或者实体对象都可以。
public class OrderService {
private OrderRepository orderRepository;
public Order updateOrder(order) {
***；
orderRepository.save(order);
***；
}
} 4
2019-12-08各层之间不断转换object 对象，从实现上看还是显得繁琐，欧老师，有简化的实现或实践么？作者回复: 现在看主要的重复性工作是在对象映射关系的建立。目前似乎还没有好的工具来辅助。
2019-12-06欧老师，那是不是意味着，接口层、应用层、领域层都用同一个DO，这样存在着一个问题，各层都耦合着领域层的DO对象。作者回复: 每层都有不同的对象的，不建议都用DO对象，正如你说的，这样耦合太高了。
2- 2019-12-05do放在领域层，po放在基础层吗？
作者回复: 是的。DO在领域层和应用层都有。