16 | 视图：如何实现服务和数据在微服务各层的协作？
该思维导图由 AI 生成，仅供参考
服务的协作
1. 服务的类型
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文从微服务架构的角度出发，探讨了微服务内部各层服务的类型、调用方式以及封装与组合。在微服务内部，不同层的服务包括Facade服务、应用服务、领域服务和基础服务，它们分别承担着用户接口处理、业务逻辑编排、核心业务逻辑和基础资源服务的职责。服务之间的调用涉及微服务内跨层服务调用、微服务之间的服务调用和领域事件驱动。此外，文章还介绍了服务的封装与组合，从基础层、领域层、应用层到用户接口层，逐级向上封装、组合和暴露服务。通过这些服务的协作，微服务得以实现业务逻辑的处理、数据交互和事件驱动。文章提供了清晰的分层架构设计思路和服务协作方式，有助于读者快速把握微服务架构的关键特点。
《DDD 实战课》，新⼈⾸单¥59
全部留言(91)
- 最新
- 精选
瓜瓜各种数据对象的转换放在那一层，很重要，比如vo与dto的转换放在前端应用，dto与do的转换放在用户接口层或者是应用层（根据用户接口层与应用层发生调用，还是微服务之间应用层发生调用而定），领域层只有DO，DO与PO的转换放在仓储实现里面，基础层只操作PO，至于仓储层的实现是放在领域层还是基础层，可以根据具体情况而定，放在基础层则为严格分层，放在领域层，则方便微服务的拆分和组合。望老师指正作者回复: 理解的非常好。
2019-11-20220
zj应用层其实我觉得入参数是DTO比较好，因为应用层是要暴漏给其他微服务调用的。然后在应用层将DTO转为DO来调用领域服务。如果调用其他微服务，则构造对方服务需要的DTO来调用。作者回复: 如果是你说的这种情况，也是可以的。
2019-11-29814
。欧老师你好 用户接口层：入参是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-20914
胖大蟲用户接口层会完成 DO 和 DTO 的互转，那不就等于将DO暴露给用户接口层了？按我的理解，DO从领域服务出来的时候就应该转换为DTO给应用层，从应用层开始往上（包括应用层）都不知道DO的存在；DO和DTO的互转，由领域服务负责，接收上层（应用层）传递的DTO，转换为DO，进而调用DO的方法完成业务逻辑，再将需要返回的数据转换为DTO返回给上层作者回复: DTO放应用层或者用户接口层都是可以的，保证外层依赖内层的原则就可以了，这些对象都在同一个微服务内。当应用服务调用其它微服务的应用服务的时候，DO和DTO的转换就在应用层。
2019-12-2567
hunter传入数据的格式校验放在哪层做？例如手机号格式校验、姓名长度校验等作者回复: 前端可以做简单格式校验，稍微复杂数据的校验在应用层。业务规则和逻辑校验在领域层。 你说的这两个前端就可以校验。
2019-11-2077
阿信关于数据对象视图定义，这块的想法和老师稍微有点区别 我的想法： https://www.processon.com/view/link/5e85bc85e4b0412013f87eb6 应用层对外是DTO，DO层不暴露到Facade层。作者回复: DTO在应用层和用户接口层都是可以的，因为在应用服务调用其他微服务的应用服务的时候，就需要完成在应用层完成DO到DTO的转换。至于DO与DTO的转换在应用层还是接口层，个人感觉两层都可以，根据具体场景选择。
2020-04-205
lamthun老师, 你好, 按照上图中的服务调用与数据组合的思路. 看图示领域层只关心repository, 不关心缓存, 缓存还是由业务层进行封装, 是这样吗? 如果是这样子的话, 在大部分应用系统中, 领域层会不会又变成薄薄的增删查改这样的一层.作者回复: 一般来说查询类型的操作不具有太多的领域逻辑，所以这类服务一般不放在领域层，领域层主要是基于聚合根ID的简单查询和聚合数据的变更操作。所以在DDD里面出现了读写分离模式，将复杂查询操作单独拿出来。或者你也可以直接在应用服务中实现复杂查询。
2020-05-2634
okjesse请问应用层需要访问repository层返回一些查询数据时，repository是只能返回DO，还是说也可以返回为DTO呢，谢谢。作者回复: repository返回的一般都是DO。 复杂查询可以采用CQRS读写分离的模式。
2019-12-1944
iMARS看完这一节有一个感觉，如果系统的业务不复杂，或者属于从0到1发展阶段的，DDD的设计方式会拖慢开发的速度，增加系统的复杂度，不适合用DDD的方式。仅仅是VO-DTO-DO-PO之间的转换就存在效能的损耗，并增加了开发工作量。而对于业务复杂，又需要规模化弹性扩展的，需要引入DDD的方式对已有系统采用自下而上的方式进行重构，以便做到业务敏捷。作者回复: 没错。这些操作主要是为了实现各层的解耦，保证领域模型的稳定，能够快速适配前端应用和后端资源逻辑的变化。所以你需要根据具体的业务场景以及性能等要求来平衡是否要做这些对象的转换，其实某些业务需求和逻辑不容易变化的业务场景是可以不做转换的。
2020-10-103
珅珅君如果需要依赖第三方的接口，应该放在哪，领域服务还是应用服务作者回复: 微服务之间的服务调用一般放在应用层通过应用服务来进行服务组合和编排。服务调用的关系图里面有微服务调用微服务外的应用服务的路线的。
2020-06-0423
