DDD实战课
欧创新
人保高级架构师
立即订阅
5029 人已学习
课程目录
已完结 23 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 学好了DDD,你能做什么?
免费
基础篇 (5讲)
01 | 领域驱动设计:微服务设计为什么要选择DDD?
02 | 领域、子域、核心域、通用域和支撑域:傻傻分不清?
03 | 限界上下文:定义领域边界的利器
04 | 实体和值对象:从领域模型的基础单元看系统设计
05 | 聚合和聚合根:怎样设计聚合?
进阶篇 (6讲)
06 | 领域事件:解耦微服务的关键
07 | DDD分层架构:有效降低层与层之间的依赖
08 | 微服务架构模型:几种常见模型的对比和分析
09 | 中台:数字转型后到底应该共享什么?
10 | DDD、中台和微服务:它们是如何协作的?
答疑:有关3个典型问题的讲解
实战篇 (10讲)
11 | DDD实践:如何用DDD重构中台业务模型?
12 | 领域建模:如何用事件风暴构建领域模型?
13 | 代码模型(上):如何使用DDD设计微服务代码模型?
14 | 代码模型(下):如何保证领域模型与代码模型的一致性?
15 | 边界:微服务的各种边界在架构演进中的作用?
16 | 视图:如何实现服务和数据在微服务各层的协作?
17 | 从后端到前端:微服务后,前端如何设计?
18 | 知识点串讲:基于DDD的微服务设计实例
19 | 总结(一):微服务设计和拆分要坚持哪些原则?
20 | 总结(二):分布式架构关键设计10问
结束语 (1讲)
结束语 | 所谓高手,就是跨过坑和大海!
DDD实战课
登录|注册

16 | 视图:如何实现服务和数据在微服务各层的协作?

欧创新 2019-11-20
你好,我是欧创新。
在 DDD 分层架构和微服务代码模型里,我们根据领域对象的属性和依赖关系,将领域对象进行分层,定义了与之对应的代码对象和代码目录结构。分层架构确定了微服务的总体架构,微服务内的主要对象有服务和实体等,它们一起协作完成业务逻辑。
那在运行过程中,这些服务和实体在微服务各层是如何协作的呢?今天我们就来解剖一下基于 DDD 分层架构的微服务,看看它的内部结构到底是什么样的。

服务的协作

1. 服务的类型

我们先来回顾一下分层架构中的服务。按照分层架构设计出来的微服务,其内部有 Facade 服务、应用服务、领域服务和基础服务。各层服务的主要功能和职责如下。
Facade 服务:位于用户接口层,包括接口和实现两部分。用于处理用户发送的 Restful 请求和解析用户输入的配置文件等,并将数据传递给应用层。或者在获取到应用层数据后,将 DO 组装成 DTO,将数据传输到前端应用。
应用服务:位于应用层。用来表述应用和用户行为,负责服务的组合、编排和转发,负责处理业务用例的执行顺序以及结果拼装,对外提供粗粒度的服务。
领域服务:位于领域层。领域服务封装核心的业务逻辑,实现需要多个实体协作的核心领域逻辑。它对多个实体或方法的业务逻辑进行组合或编排,或者在严格分层架构中对实体方法进行封装,以领域服务的方式供应用层调用。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(38)

  • zj
    应用层其实我觉得入参数是DTO比较好,因为应用层是要暴漏给其他微服务调用的。然后在应用层将DTO转为DO来调用领域服务。如果调用其他微服务,则构造对方服务需要的DTO来调用。

    作者回复: 如果是你说的这种情况,也是可以的。

    2019-11-29
    3
  • 欧老师你好

    用户接口层:入参是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、是否要做数据转换?主要是考虑解耦,这样各层不必受其它层的数据限制,它类似齿轮,通过数据转换来做适配。如果从前端到后端数据对象都是一样的,用一个对象其实也是可以的。要结合自己的场景来分析。

    2019-11-20
    2
    3
  • 胡杨
    领域实体是entity,领域对象是do,那Do就是entity么?
    是的话,那po到do的转换一般是EF等框架自己做的了吧?

    作者回复: 是的,实体就是DO。
    PO与DO的互转,Java大部分都需要自己写代码转换。
    .net倒是有一些框架可以自动去做映射,比如你说的EF。

    2019-12-13
    1
  • 墨名次
    在数据试图这里,如果有用户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

    作者回复: 是的,但是有的时候不一定是一对一的关系。

    2019-11-20
    1
  • 张迪
    传入数据的格式校验放在哪层做?例如手机号格式校验、姓名长度校验等

    作者回复: 前端可以做简单格式校验,稍微复杂数据的校验在应用层。业务规则和逻辑校验在领域层。
    你说的这两个前端就可以校验。

    2019-11-20
    3
    1
  • 欧老师,微服务之后,前后端分离。前端和后端的登陆认证用什么来做呢?基于token的方式,“退出登录”是假的退出吧?是不是只在前端应用删除了保存的key,对于后端应用,这个key还是生效的

    作者回复: 我们前端用JWT实现单点登录。后端微服务的服务调用通过API鉴权来控制。

    2019-11-20
    1
    1
  • William.加
    老师,微服务之间分布式事务,是有修改就用,还是应该根据具体业务做取舍?

    作者回复: 根据你的业务来取舍吧,如果数据不一致没关系,或者数据不重要,部分数据丢了也可以,就可以不用。
    如果是核心业务数据或者涉及到钱的业务数据,分布式事务就必不可少了。

    2019-11-20
    1
  • 密码123456
    设计不同的对象,能够保证。当基于下层业务变化时。只需要更改,对象的转化即可。不需要对业务逻辑进行变更。对吗?

    作者回复: 是的。除非带来业务逻辑变化了,才去做变更。

    2019-11-20
    1
  • okjesse
    请问应用层需要访问repository层返回一些查询数据时,repository是只能返回DO,还是说也可以返回为DTO呢,谢谢。

    作者回复: repository返回的一般都是DO。
    复杂查询可以采用CQRS读写分离的模式。

    2019-12-19
    1
  • 电商小能手
    老师,“领域服务和应用服务都可以调用仓储服务接口,通过仓储服务实现数据持久化。” 聚合根里也可以调用仓储服务接口吧?

    作者回复: 是的,但是一般聚合根用的少,很多情况聚合根要作为对象传到基础层。

    2019-12-13
  • OTM
    用户接口层对客户端提供接口访问,应用层提供服务之间的访问,建议dto统一在应用层进行检验;而且应用层的服务也需要注册成rpc或者restful的,同时访问路径与访问权限不一样

    作者回复: 都可以的,在应用层更统一。

    2019-12-11
  • Geek_aa8017
    应用层和服务层都有各自的po?对照着老师的结合自己的项目来做一遍发现有好多问题都不知道怎么下手啊

    作者回复: PO只在基础设施层。它与应用层和领域层的DO互转。

    2019-12-11
    1
  • 番茄炒西红柿
    想问一下领域层,实体想要调用仓储接口的时候,参数接口的注入放在实体中吗,还是放在领域服务里面

    作者回复: 仓储接口可以被领域服务和应用服务调用,在仓储接口中传入实体ID或者实体对象都可以。
    public class OrderService {
    private OrderRepository orderRepository;
    public Order updateOrder(order) {
    ***;
    orderRepository.save(order);
    ***;
    }
    }

    2019-12-09
    4
  • Beck
    各层之间不断转换object 对象,从实现上看还是显得繁琐,欧老师,有简化的实现或实践么?

    作者回复: 现在看主要的重复性工作是在对象映射关系的建立。目前似乎还没有好的工具来辅助。

    2019-12-08
  • 周桃春
    欧老师,那是不是意味着,接口层、应用层、领域层都用同一个DO,这样存在着一个问题,各层都耦合着领域层的DO对象。

    作者回复: 每层都有不同的对象的,不建议都用DO对象,正如你说的,这样耦合太高了。

    2019-12-06
    2
  • Geek_aa8017
    do放在领域层,po放在基础层吗?

    作者回复: 是的。DO在领域层和应用层都有。

    2019-12-05
  • 冷たい風
    《再问一次》老师请问一个问题呢:
    应用层可以直接调用不涉及领域对象的仓储服务,那这种仓储服务应该放在哪个领域对象下面呢?
    我的问题是这种仓储服务应该放在哪个领域下面?(而不是之前老师回答的问题)

    作者回复: 如果数据是跟聚合实体相关的数据库复杂查询,你可以放在聚合的目录下。如果跟聚合无关,只是对缓存文件等的数据查询,放基础层是可以的。
    我把仓储放在聚合目录下,主要是考虑以后聚合的代码重组方便。
    你说的领域对象是不是聚合?不知道理解的对不对?

    2019-12-04
  • 冷たい風
    老师请问一个问题呢:
    应用层可以直接调用不涉及领域对象的仓储服务,那这种仓储服务应该放在哪个领域对象下面呢?

    作者回复: 应用层直接调仓储一般是缓存或其它数据组件,或者大批量的数据库查询服务。

    2019-12-04
    1
  • 鲲哥
    欧老师你好
    文中你主要讲了跨层的调用,那同级的服务能互相调用吗?比如,领域内或领域间的实体能互相调用吗?领域服务能否互相调用?还是说遇到同级调用调用的,都向上层提取,由上层服务进行编排?

    作者回复: 同一个聚合内的实体一般都是通过聚合根或者实体之间的引用来调用。
    这几个模型没说同级能不能调,但我个人觉得从代码实现来看,同层调用应该也是可以的。但是要尽量将同层可复用的逻辑往下层去沉淀,然后再提供给上层。

    2019-11-27
  • FIGNT
    1.应用层可以直接调用领域聚合的方法吗,还是说要通过领域服务去调用?
    2.实体的方法一定要聚合封装一下吗?能不能先取出实体再调用方法呢?
    3.多个聚合之间访问只能在应用层调用通过聚合id访问?
    4. 一个聚合一个仓储,聚合之间有相同的内容怎么处理?比如一个大聚合做主流程业务,包含了大部分的实体,小聚合只是维护性的增删改,小聚合完成增删改之后,大聚合需要同步数据吗?

    作者回复: 1,可以的,松散分层架构就是这样的。严格分层架构需要封装后给应用层。
    2,实体方法需要通过聚合根来调用。
    3,是的。
    4,你可以将小聚合实体设计为大聚合实体的值对象。

    2019-11-23
收起评论
38
返回
顶部