作者回复: 如果是你说的这种情况,也是可以的。
作者回复: 1、可以的。
2、是否要做数据转换?主要是考虑解耦,这样各层不必受其它层的数据限制,它类似齿轮,通过数据转换来做适配。如果从前端到后端数据对象都是一样的,用一个对象其实也是可以的。要结合自己的场景来分析。
作者回复: 前端可以做简单格式校验,稍微复杂数据的校验在应用层。业务规则和逻辑校验在领域层。
你说的这两个前端就可以校验。
作者回复: DTO放应用层或者用户接口层都是可以的,保证外层依赖内层的原则就可以了,这些对象都在同一个微服务内。当应用服务调用其它微服务的应用服务的时候,DO和DTO的转换就在应用层。
作者回复: 是的,实体就是DO。
PO与DO的互转,Java大部分都需要自己写代码转换。
.net倒是有一些框架可以自动去做映射,比如你说的EF。
作者回复: 是的,但是有的时候不一定是一对一的关系。
作者回复: 我们前端用JWT实现单点登录。后端微服务的服务调用通过API鉴权来控制。
作者回复: 根据你的业务来取舍吧,如果数据不一致没关系,或者数据不重要,部分数据丢了也可以,就可以不用。
如果是核心业务数据或者涉及到钱的业务数据,分布式事务就必不可少了。
作者回复: 是的。除非带来业务逻辑变化了,才去做变更。
作者回复: 除了增删改查,还有实体的业务行为,具体表现为实体的方法。
作者回复: A和B可以分别返回两个DO,然后将它们组装成你需要的前端展现的DTO就可以了。
作者回复: 建立这么多O主要是为了解耦,如果系统不够复杂,业务和需求不会经常变动,可以根据自己的需要来定。其实用起来也还可以,你可以用工厂模式。
作者回复: repository返回的一般都是DO。
复杂查询可以采用CQRS读写分离的模式。
作者回复: 是的,但是一般聚合根用的少,很多情况聚合根要作为对象传到基础层。
作者回复: 都可以的,在应用层更统一。
作者回复: PO只在基础设施层。它与应用层和领域层的DO互转。
作者回复: 仓储接口可以被领域服务和应用服务调用,在仓储接口中传入实体ID或者实体对象都可以。
public class OrderService {
private OrderRepository orderRepository;
public Order updateOrder(order) {
***;
orderRepository.save(order);
***;
}
}
作者回复: 现在看主要的重复性工作是在对象映射关系的建立。目前似乎还没有好的工具来辅助。
作者回复: 每层都有不同的对象的,不建议都用DO对象,正如你说的,这样耦合太高了。
作者回复: 是的。DO在领域层和应用层都有。