DDD实战课
欧创新
人保高级架构师
立即订阅
4865 人已学习
课程目录
已完结 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实战课
登录|注册

08 | 微服务架构模型:几种常见模型的对比和分析

欧创新 2019-10-30
你好,我是欧创新。
在上一讲中我重点介绍了 DDD 分层架构,同时我也提到了微服务架构模型其实还有好多种,不知道你注意到了没?这些架构模型在我们的实际应用中都具有很高的借鉴价值。
那么今天我们就把 DDD 分层架构(详情介绍如有遗忘可回看 [第 07 讲] )、整洁架构、六边形架构这三种架构模型放到一起,对比分析,看看如何利用好它们,帮助我们设计出高内聚低耦合的中台以及微服务架构。

整洁架构

整洁架构又名“洋葱架构”。为什么叫它洋葱架构?看看下面这张图你就明白了。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。
在整洁架构里,同心圆代表应用软件的不同部分,从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容,比如用户界面和基础设施。
整洁架构最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。
在洋葱架构中,各层的职能是这样划分的:
领域模型实现领域内核心业务逻辑,它封装了企业级的业务规则。领域模型的主体是实体,一个实体可以是一个带方法的对象,也可以是一个数据结构和方法集合。
领域服务实现涉及多个实体的复杂业务逻辑。
应用服务实现与用户操作相关的服务组合与编排,它包含了应用特有的业务流程规则,封装和实现了系统所有用例。
最外层主要提供适配的能力,适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配,比如数据库、缓存、文件系统和消息中间件等。
红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DDD实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(27)

  • ANYI
    微服务之间通过服务内部的应用层来连接多个微服务,微服务之间的相互调用;有两个疑问:1,微服务之间互相调用应该是什么样子?会不会就出现了网状微服务的调用关系结构了
    2,是把这个夸多个微服务的应用层独立起来成为一个微服务(类似BFF微服务,没有领域)减少微服务之间调用关系?微服务之间就应该减少依赖调用?

    作者回复: 微服务之间要分两种情况,一种是项目级的少量微服务之间的调用。这样的调用可以放在微服务内的应用层,没必要再单独拿出一个微服务来进行服务组合和编排。
    另外一种是复杂的企业级微服务调用和组合。拿出一个独立的BFF微服务的主要目的,一个是避免在一个微服务内组合太多的微服务的应用服务。二是,通过BFF微服务编排组合,可以减少由于前台的需求变化,传导到后端微服务中,可以降低后端微服务的发版频率,保持后端微服务的稳定。

    2019-11-06
    3
  • 密码123456
    分层架构、整洁架构、六边形架构有什么区别?

    作者回复: 它们几个其实是一点一点继承和发展过来的,在大的分层上基本上没什么太大的差异,思路基本是一致的,都是以领域模型为中心,加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。

    2019-10-30
    1
    3
  • sqyao
    请问老师,在设计微服务接口编排的时候,有哪些需要注意的地方?最好可以在github上给一个demo。

    作者回复: 你是说应用服务的编排吗?
    你把这种编排理解成在同一个微服务内,一个方法对多个不同方法的调用就可以了,如果涉及到外部微服务的接口调用,你需要做DO与DTO的数据转换。

    2019-11-19
    1
    2
  • TH
    想起了一句话:软件开发中遇到的所有问题,都可以通过增加一层抽象来解决。

    对于依赖倒置的实现不是很清楚,按我的理解就是面向接口编程,由调用方将基础设施层的具体实现传入到被调用的服务,老师可以详细解释一下吗?

    作者回复: 是这样的。直白一点就是业务的归业务,基础的归基础,两者通过一层来适配,具体就是通过接口的方式。

    2019-10-30
    1
    2
  • Geek_d94e60
    如果有了BFF这一层做统一编排,微服务内部还需要编排吗?如果碰到如下两种方案
    A调用B, B再调用C
    A调用B , A再调用C
    刚开始识别不出复用性,两个方案感觉都可行,如何抉择,有什么原则指导吗?

    作者回复: BFF做微服务之间的编排。微服务内的应用服务主要做领域服务的编排和聚合之间的协调。BFF是微服务之间的,应用服务是微服务内的。

    2019-11-13
    1
  • lightSky
    关于这几种架构的区别,我觉得可以有一条原则作为主线,就是依赖倒置,不管是clean架构还是分层,或者六边形架构,都是高层次依赖于低层次的接口,都是为了实现关注点分离,提高代码的内聚性,隔离变化,最终达到稳定性的同时拥有良好的扩展性,架构最终都是趋同的,不同点就是他们在层与层之间的扩展点的方式不同。😄
    2019-11-05
    1
  • 瓜瓜
    看完后,就是没区别。

    作者回复: 没有差异就不会有这么多叫法😄。它们几个其实是一点一点继承和发展过来的,在大的分层上基本上没什么太大的差异,思路基本是一致的,都是以领域模型为中心,加上用于编排的应用层逻辑。但是在分层的内部有一些小的差异。包括外部的适配方式也有差异。

    2019-10-30
    1
  • 何沛
    思考题:
    面向用户的展现层可以快速响应外部需求进行调整和发布,灵活多变,
    应用层通过服务组合和编排实现业务流程的快速适配上线,
    领域层基本就不需要太多的变化了,
    如果真的万不得已要修改领域层,领域层也要遵循面向对象的6大原则(单一职则原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则),保证领域层高内聚低耦合。

    作者回复: 是的,领域层也是少不了要演进的😄。

    2019-10-30
    1
    1
  • Asia
    项目级微服务的那张图中,调用其他微服务的功能往往发生在领域层的领域服务中,甚至是领域模型的方法中,因为领域的某个属性或者能力依赖于其他服务,这种情况是设计的不合理导致的还是属于正常的呢?

    作者回复: 微服务之间的调用都是在应用层。

    2019-10-30
    2
    1
  • 项目级微服务和企业级微服务的例子里,每个微服务都是有自己单独的注册中心?

    我理解的是,一套微服务体系,包括:一个注册中心集群,微服务A集群,微服务B集群 等微服务集群,API网关集群。所有服务均通过API网关对外暴露,API网关还负责鉴权、限流、路由分发等。

    作者回复: 不是每个微服务都有自己的API网关,只是做一个示例。多个微服务可以共用一个API网关的。
    在企业级中台设计的时候可以一个中台多个微服务共用一个网关。

    2019-10-30
    1
  • Jxin
    回答问题:
    1.为了支持外部应用,内部核心业务必须增加新逻辑。这种情况主要是要提高对价值的意识和风险的敏感。尽量不去加核心逻辑的代码,如果加了,必须是有足够价值的特性,且风险点可控或无。
    2.为了支持外部应用,内部核心业务存在现有功能逻辑,但需调整兼容。这种情况就对该核心逻辑做进一步抽象,将通用部分复用,常变部分做抽象,实现更细力度的配置策略的定制能力。(当然也是要有足够价值)。

    提问:
    老的大项目并没有合理的架构分层。套到整洁架构上来看。
    1.领域服务层会干领域模型的活。(贫血领域模型)
    2.领域服务层会干应用层的活。(领域层大量rpc调用外部服务,并依托外部服务返回的dto做大量业务)
    3.基础层会干领域服务的事。(dao层写业务,发mq,存solr,redis)

    对于以上情况,做既有代码改善的小步重构,老师可有好套路或则思路?毕竟这种项目要大改规范,成本(时间)和风险(线上事故)都是接受不了的。(我重构了一遍,但是是业务架构上的。领域服务和基础层的职责越界并没有全量调整,仅是跟着需求,若涉及到就修修补补)

    作者回复: 这里你可以考虑单体架构的演进方式。可以先对系统做整体的领域建模分析,分解成多个不同的子域,建立领域模型。再根据优先级将部分领域模型对应的功能和数据从原来的单体应用中拆分出来,拆分为微服务。对原来的单体系统的前端提供API服务,原有系统的前端界面保持不变,整个架构演变用户无感知。当所有领域模型的微服务建设完成后,就可以抛弃原来的单体应用了。

    2019-10-30
    1
  • 吃饭饭
    【在微服务架构中,应用层、领域层和基础层解耦是通过仓储模式,采用依赖倒置的设计方法来实现的】这种依赖倒置具体指的什么?是每个微服务不用配置自己的数据库,直接用数据仓库?数据库更换或者出问题了,自动切换配置屏蔽故障库?不太明白

    作者回复: 仓储模式是一种设计模式。它是在应用业务逻辑和数据层之间增加的一个抽象层,应用逻辑通过调用仓储接口的方式与数据层交互,与数据相关的实现都在仓储实现中实现,这样就可以避免在应用逻辑中混入数据相关的实现逻辑。从而就解耦了应用逻辑和数据逻辑。在基础资源变化时不会对应用逻辑有太大的影响。

    2019-10-30
    2
    1
  • 密码123456
    ddd分层、整洁架构、六变形架构。没看出太大的区别。核心都是应用层、领域层。 这三种架构的基础层,其它各层都可访问?

    作者回复: 基础层是面向所有层的。

    2019-10-30
    1
    1
  • 三木子
    DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心,实行分层架构,内部核心业务逻辑与外部应用、资源隔离并解耦

    作者回复: 是这样的。

    2019-10-30
    1
  • Frank
    看了之后,干货很多,但是对于3种架构的区别傻傻分不清,还请老师解答一下哈

    作者回复: 它们的设计思想都是为了分离关注点,在应用逻辑以下的部分思路基本都是一致的,主要是核心业务逻辑和领域模型。其实都可以用DDD的战略方法来设计领域模型。主要区别还是在外围的适配上,端口适配器会给每个不同的场景,设计一个端口提供调用服务,这种是主动适配。还有一种是资源方面服务,是被动适配的方式。所有的外围对象都是平等的,可以是自动化的测试工具,也可以是APP。
    DDD是通过接口层来对外提供服务接口,基础资源通过仓储依赖倒置使用资源,并实现解耦。

    2019-11-27
  • 白开水有三种味道
    原子层是不是企业的最底层的流程?比如销售记账,开票那些的

    作者回复: 原子业务是实体或值对象的自身的业务行为和逻辑。最底层的流程应该领域服务,它有协调实体的职责。

    2019-11-26
  • 周孟
    个人觉得这章节的关键在下面这句话:“可以说,这三种架构都考虑了前端需求的变与领域模型的不变。”,但一时没能想明白,目前接触的保险行业系统因产品变化,前后台都要改动没能很好识别出来领域模型不变这一点,老师能给解惑一下吗?

    作者回复: 领域模型大多提供的是实体相关的基础原子服务,只要基础模型不变,业务逻辑就不会变,所以领域模型基本就能保持稳定。而前端为了响应外部需求或流程的变化,所以会频繁的变动,但是这种变动可以通过应用层的编排很快做出调整,需求不会传导到领域层,所以领域模型的业务逻辑保持不变。

    2019-11-25
  • krugle
    基础层怎么才能做到通用 比如前端展示突然要多一个字煅 那基础层不是也要改吗 从上到下都要改

    作者回复: 前端展示的时候获取的数据是按需提供的,如果DO对象本身就有,只需要在DO转DTO的时候,加上就可以了,这个需求不会传导到基础层数据库的。
    如果新增的字段涉及到领域层核心的实体属性或者数据库结构,确实需要从上到下修改。

    2019-11-24
  • 张迪
    怎么感觉中台和ESB好像

    作者回复: 差的太多了。完全不在一个水平的东西。

    2019-11-04
  • miniluo
    看完了,晚上回去画画图,这样深刻点。
    2019-11-04
收起评论
27
返回
顶部